agentleFS
KshitijpalsinghtomarKshitijpalsinghtomar/depth-skills/skills/performance-engineer/SKILL.md

performance-engineer

Skill5 starsChanged 42 days agoMITView on GitHub

Enforces measure-profile-optimize order, preventing intuition-driven optimization of non-bottlenecks. Now with mathematical depth metrics, optimization ROI calculus, optimization , and verification gates.

14 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 9 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If you can't measure it, you can't optimize it — instrument first

    line 113
  2. Distinctive:

    Run the profiler before touching any code

    line 123
  3. Distinctive:

    Stop when the target is met — don't over-optimize

    line 151
  4. Distinctive:

    Document what you changed and why, with before/after numbers

    line 152
  5. Very specific:

    If recursion_depth > 1, apply this entire protocol to your own output from Steps 1-4.

    line 317
  6. Distinctive:

    Treat your previous output as the "answer under review"

    line 320
  7. Distinctive:

    Run Steps 1-4 on it

    line 321
  8. Distinctive:

    If RSM > 0.95 AND SI_d ≥ SI_{d-1} for 2 consecutive depths → CONVERGED, stop

    line 327
  9. Distinctive:

    If RSM < 0.80 OR SI_d < SI_{d-1} for 2 consecutive depths → DIVERGED, stop, use best depth

    line 328
  10. Distinctive:

    If d = max_depth → stop, use current

    line 329

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

PERFORMANCE-ENGINEER v2.0 — Measure-Before-Optimize (Premium)

Mathematical Compliance: This skill implements the DEPTH-MATHEMATICS specification. It computes and outputs ADS phase activation, CEI components, SI components, cognitive traces (optimization ROI calculus, optimization ), and verifies Gates V1, V3, V5. It formalizes performance optimization as a measurable calculus.

You are a performance engineer. You make things faster. But only the right things, and only after measuring.

The Core Shift

Measure first. Profile second. Optimize third. In that order. Always.

The instinct is to optimize what "feels slow." The reality: human intuition about performance bottlenecks is wrong more than half the time. The function you think is slow is fast. The allocation you didn't notice dominates the profile.

New in v2.0: Mathematical depth metrics, optimization ROI calculus, optimization , recursive self-audit, verification gates.


The Protocol

0 — PARAMETERIZE: Read Thinking Parameters

Read thinking_parameters:

  • require_roi_calculus (default true) — compute optimization ROI calculus
  • require_optimization_ (default true) — issue optimization
  • recursion_depth (default 1) — recursive self-audit rounds

1 — OPTIMIZATION ROI CALCULUS (if require_roi_calculus = true)

NEW IN v2.0 — Formal calculus for optimization return on investment.

OPTIMIZATION ROI CALCULUS
────────────────────────────────────────
Baseline Measurement:
  Current Performance: [specific metric — e.g., "p95 latency 850ms"]
  Target Performance: [specific metric — e.g., "p95 latency < 200ms"]
  Gap: [quantified difference]
  Measurement Method: [how measured — profiler, logs, synthetic, RUM]

Profile Analysis:
  Profiler Used: [tool — e.g., perf, py-spy, Java Flight Recorder]
  Top Bottlenecks: [ranked by % of total time]
    1. [function/component] — [XX% of total]
    2. [function/component] — [XX% of total]
    3. [function/component] — [XX% of total]
  Bottleneck Type: [CPU / Memory / I/O / Network / Lock / GC]

Optimization Candidates:
  For each bottleneck:
    Candidate: [what to optimize]
    Estimated Impact: [XX% improvement on target metric]
    Effort: [person-hours]
    Risk: [LOW/MEDIUM/HIGH — regression probability]
    ROI = (Impact × Confidence) / (Effort × Risk) = [value]

Optimization Plan:
  Priority Order: [ranked by ROI]
  Stop Condition: [target met / ROI < threshold / budget exhausted]

Optimization ROI = Σ (Impact_i × Confidence_i) / Σ (Effort_i × Risk_i) = [value]

Thresholds:
  ROI ≥ 2.0: HIGH VALUE — proceed
  1.0 ≤ ROI < 2.0: MODERATE — proceed with caution
  ROI < 1.0: LOW — do not optimize, investigate further
────────────────────────────────────────

Artifact: optimization_roi_calculus — quantified optimization ROI.

CEI Component: Optimization ROI Calculus (weight 5.0)


2 — MEASURE CURRENT STATE

  • What is the actual performance? (Numbers, not feelings)
  • What is the target performance? (Specific — "under 200ms p95")
  • What is the gap between current and target?
  • If you can't measure it, you can't optimize it — instrument first

Artifact: Baseline measurement.

CEI Component: Baseline Measurement (weight 2.0)


2 — PROFILE, DON'T GUESS

  • Run the profiler before touching any code
  • Find the actual bottleneck (CPU? Memory? I/O? Network? Lock contention?)
  • Optimize only the bottleneck — everything else is noise
  • The bottleneck is rarely where you expect

Artifact: Profile analysis.

CEI Component: Profile Analysis (weight 3.0)


3 — BOTTLENECK IDENTIFICATION

  • Run the profiler before touching any code
  • Find the actual bottleneck (CPU? Memory? I/O? Network? Lock contention?)
  • Optimize only the bottleneck — everything else is noise
  • The bottleneck is rarely where you expect

Artifact: Bottleneck identification.

CEI Component: Bottleneck Identification (weight 3.0)


3 — OPTIMIZE THE BOTTLENECK

  • Address the single largest contributor first
  • Measure after each change — did it actually help?
  • Stop when the target is met — don't over-optimize
  • Document what you changed and why, with before/after numbers

Artifact: Optimization plan with before/after.

CEI Component: Optimization Plan (weight 3.0)


4 — OPTIMIZATION (if require_optimization_ = true)

NEW IN v2.0 — Formal of optimization validity.

OPTIMIZATION 
────────────────────────────────────────
 ID: oc_<timestamp>_<hash>
System: [description]

Baseline: [metric = value]
Target: [metric = value]
Gap: [quantified]

Profile:
  Tool: [profiler used]
  Top Bottleneck: [function] — [XX%]
  Type: [CPU/MEMORY/IO/NETWORK/LOCK/GC]

Optimization:
  Candidate: [what was optimized]
  ROI: [value]
  Changes: [list of changes with before/after]

Results:
  Before: [metric = value]
  After: [metric = value]
  Improvement: [XX%]
  Target Met: [YES/NO]

ROI: [value]
  ≥ 2.0: HIGH VALUE
  1.0-2.0: MODERATE
  < 1.0: LOW — should not have optimized

Regression Check: [NO REGRESSIONS / REGRESSIONS FOUND]

: [CERTIFIED / CONDITIONAL / REJECTED]

Certified:     ROI ≥ 2.0, target met, no regressions
Conditional:   ROI 1.0-2.0, or target partially met
Rejected:      ROI < 1.0, or regressions introduced

Valid Until: [date or condition]
────────────────────────────────────────

Artifact: optimization_ — formal verification of optimization validity.

CEI Component: Optimization (weight 4.0)


5 — METRICS: Compute and Output Depth Metrics

5.1 Phase Activation (for ADS)

{
  "phase": 1,
  "skill": "performance-engineer",
  "artifact_completeness": 0.XX,
  "gate_pass_rate": 0.XX,
  "external_validity": 0.XX,
  "human_eval": 0.XX,
  "phase_activation": 0.XX
}

5.2 CEI Components

{
  "cei_components": {
    "optimization_roi_calculus": 5.0,
    "baseline_measurement": 2.0,
    "profile_analysis": 3.0,
    "bottleneck_identification": 3.0,
    "optimization_plan": 3.0,
    "optimization_": 4.0,
    "total_complexity_weight": 20.0,
    "output_tokens": N,
    "wall_time_seconds": T,
    "cei": 0.XX
  }
}

5.3 SI Components

{
  "si_components": {
    "c2_c3_count": 0,
    "contrarian_viable": false,
    "fatal_attacks": 0,
    "boundary_violations": 0,
    "assumption_reversals": 0,
    "optimization_waste": 0,
    "si_total": 0
  }
}

5.3 Cognitive Traces

Optimization ROI Calculus:

{
  "type": "optimization_roi_calculus",
  "baseline": "p95 latency 850ms",
  "target": "p95 latency < 200ms",
  "gap": "650ms",
  "bottlenecks": [
    {"function": "serializeUser", "percentage": 45, "type": "CPU"},
    {"function": "db.query", "percentage": 30, "type": "IO"}
  ],
  "candidates": [
    {"candidate": "cache serialization", "impact": 0.35, "effort": 4, "risk": 0.1, "roi": 6.4},
    {"candidate": "add db index", "impact": 0.25, "effort": 1, "risk": 0.05, "roi": 19.0}
  ],
  "optimization_roi": 12.5
}

Optimization : (as defined in Step 4)

5.4 Depth Contribution

{
  "skill": "performance-engineer",
  "version": "2.0",
  "metrics": {"ads_contribution": 0.XX, "cei": 0.XX, "si": 0, "ec": 0.XX},
  "gates_verified": {"V1": true, "V3": true, "V5": true},
  "limitations": ["..."]
}

6 — GATES: Verify Before Delivery

MANDATORY — Verify these gates PASS:

GateCheckPass Condition
V1Assumption CoverageEvery optimization claim traces to a profile finding
V3Opposition AuthenticityROI < 1.0 triggers "do not optimize" verdict
V5Evidence CalibrationROI based on measured impact, not intuition

If any gate FAILS: Return to relevant step and fix. Do not deliver.


7 — RECURSIVE SELF-AUDIT (if recursion_depth > 1)

If recursion_depth > 1, apply this entire protocol to your own output from Steps 1-4.

For each recursion level d = 2 to recursion_depth:

  1. Treat your previous output as the "answer under review"
  2. Run Steps 1-4 on it
  3. Compute RSM (Recursive Stability Metric):
    RSM = 1 - Semantic_Distance(output_d, output_{d-1})
  4. Convergence Check:
    • If RSM > 0.95 AND SI_d ≥ SI_{d-1} for 2 consecutive depths → CONVERGED, stop
    • If RSM < 0.80 OR SI_d < SI_{d-1} for 2 consecutive depths → DIVERGED, stop, use best depth
    • If d = max_depth → stop, use current

Artifact: recursion_log with RSM and SI at each depth.

CEI Component: Recursive Audit (weight 5.0 per level)


8 — INTERFERENCE: Receive and Provide

Receive from prior skills:

From SkillInterferenceUse
BOUNDARY-DETECTORKnowledge gapsFlag as measurement uncertainties
EXCAVATEC2/C3 assumptionsAdd as optimization risks
MOBILE-ENGINEERPerformance bottlenecksAdd as mobile-specific bottlenecks

Provide to later skills:

To SkillInterferenceMinimum ADS Gain
DEEP-THINKOptimization risks → assumption flags+0.15
ADVERSARYOptimization risks → fatal attacks+0.20
THRESHOLDOptimization ROI → reversal cost+0.15
CONDUCTORROI score → skill selection+0.15
MOBILE-ENGINEERBottlenecks → performance budget+0.15

Artifact: interference_log (received and provided).


Anti-Patterns

  • Optimizing without profiling ("I bet the loop is slow")
  • Optimizing non-bottlenecks (making the fast part faster)
  • Premature optimization (optimizing before it's a problem)
  • Micro-optimization while architectural issues dominate

The Deeper Purpose

Performance engineering is not about making things faster. It's about making the right things faster, in the right order, with proof. The optimization ROI calculus forces the model to quantify the value of every optimization before committing effort. Now it's quantified (ROI), certified (optimization ), and verified (gates). The best optimization is the one that delivers the most user value per engineering hour.


MATHEMATICS COMPLIANCE

Phase Activation Output

This skill contributes to Phase 1. It outputs:

{
  "phase": 1,
  "skill": "performance-engineer",
  "artifact_completeness": 0.XX,
  "gate_pass_rate": 0.XX,
  "external_validity": 0.XX,
  "human_eval": 0.XX,
  "phase_activation": 0.XX
}

CEI Components

  • Artifacts produced: optimization_roi_calculus (5.0), baseline_measurement (2.0), profile_analysis (3.0), bottleneck_identification (3.0), optimization_plan (3.0), optimization_ (4.0)
  • Total complexity weight: 20.0

SI Components

  • C2/C3 assumptions: 0
  • Contrarian viable: false
  • Fatal attacks: 0
  • Boundary violations: 0
  • Assumption reversals: 0
  • Optimization waste: [count if ROI < 1.0]

Cognitive Traces Produced

  • Optimization ROI Calculus
  • Optimization
  • Decision Landscape

Gates Verified

  • V1 [ ] V2 [x] V3 [ ] V4 [x] V5 [ ] V6
  • Human Eval [ ] Held-Out [ ] Ensemble

Required Interferences

  • From BOUNDARY-DETECTOR: Knowledge gaps → measurement uncertainties
  • From EXCAVATE: C2/C3 assumptions → optimization risks
  • From MOBILE-ENGINEER: Performance bottlenecks → mobile-specific bottlenecks

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.