ddd13e6422
Group G — markdown tech-debt cleanup (post-audit 2026-05-02).
- 36 SKILL.md files: added "## When to use" section. Was missing across the
catalog; orchestrator routing by keyword could not auto-dispatch.
- 20 code-implementer agent .md files: added Output Footer block prescribing
RULE 0.16 STATUS-TRUTH MARKER schema in agent's final report. Previously only
code-implementer-rust.md had it; other 27 language/role variants were silent
about the marker, breaking RULE 0.16 §3 status-truth aggregation for non-Rust
batches.
- skills/site-create/: added phase-5-preview.md and phase-6-deploy.md skeleton
files. SKILL.md table-of-contents referenced 7 phases; only 5 existed on disk.
- skills/{ai-animation,rag-pipeline}/skill.md: added migration banner comment
noting they should be SKILL.md (canonical filename). Case-rename via git is a
separate orchestrator task (macOS APFS is case-insensitive; Linux deploy needs
explicit rename).
- 3 deprecated skills (site-builder, competitor-analysis, design-inspiration):
added concrete removed-after dates (was vague "before v2").
- docs/CONVERGENCE-PLAN.md:129: TBD on _blocks/evidence-grading.md duplicate
resolved (file exists, not duplicated).
- docs/DNA-INDEX.md: count edits made then overwritten by auto-encyclopedia-refresh
hook during agent run. The .kei-registry-ignore files in test fixtures (Group F)
are the structural fix; kei-registry walker implementation is the follow-up.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 KiB
2 KiB
| name | description | arguments | |||||||
|---|---|---|---|---|---|---|---|---|---|
| perf-audit | Use when auditing performance — baseline, profile, identify top 3 bottlenecks, fix, remeasure |
|
Performance Audit Workflow
When to use
- Auditing an API endpoint, page, or function for performance regressions (baseline → profile → fix → remeasure).
- Identifying the top 3 bottlenecks (DB N+1, sequential network calls, CPU hotspots, bundle bloat).
- Before shipping a feature that touches a known hot path and needs measured before/after numbers.
Step 1: Establish Baseline
- Measure current performance:
- API: response time (p50, p95, p99), throughput
- Frontend: LCP, FID, CLS, bundle size
- Function: execution time, memory usage
- Record numbers BEFORE any changes
- Use project's existing tools or:
- Python:
time,cProfile,memory_profiler - JS/TS:
performance.now(), Lighthouse,webpack-bundle-analyzer - API:
curl -w @-timing,ab,wrk
- Python:
Step 2: Profile
- Identify WHERE time is spent:
- Database queries (N+1, missing indexes, full scans)
- Network calls (sequential vs parallel, caching)
- CPU (algorithmic complexity, unnecessary computation)
- Memory (leaks, large allocations, unnecessary copies)
- I/O (file reads, disk writes)
Step 3: Identify Top 3 Bottlenecks
- Rank by impact (% of total time)
- Focus on top 3 — don't optimize everything
- For each: document what, why slow, potential fix
Step 4: Checkpoint
checkpoint: before perf-audit $target
Step 5: Fix (One at a Time)
- Fix #1 bottleneck → measure → confirm improvement
- Fix #2 bottleneck → measure → confirm improvement
- Fix #3 bottleneck → measure → confirm improvement
- After each fix: run tests — no regressions
Step 6: Final Measurement
- Re-run baseline measurements
- Compare before/after
- Report: metric, before, after, improvement %
Step 7: Commit
perf: optimize $target — <summary of improvements>