菜单
Profile, optimize, and benchmark performance — measure baseline first, find the real bottleneck, optimize one thing at a time, prove it with numbers. Use on "it's slow", "optimize this", "improve performance", "reduce latency", "profile this", or shared timing/benchmark output.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Write documentation someone will actually read — READMEs, guides, API references, runbooks — short, scannable, example-first, and verified against the code. Trigger on "write docs", "document this", "write a README", "explain how to use this", "our docs are too long/confusing", or a doc that needs rewriting for humans.
Review a diff, branch, or PR for correctness bugs, security issues, and simplification opportunities; findings to docs/<feature-name>/REVIEW.md. Trigger on "review this", "code review", "security review", "audit this", or after something is implemented and needs checking before merge.
Write docs/<feature-name>/PLAN.md with phased, checkbox-driven steps for a feature, refactor, upgrade, or infrastructure change. Trigger on "create/make a plan", "plan this feature/refactor/upgrade", any request to document steps before coding, and proactively when complexity warrants a written plan.
Decide a feature's shape before planning — system design, data model, API contract, UI/UX, whichever apply — and write docs/<feature-name>/DESIGN.md. Trigger on "design this feature/API/schema/UI", "how should we structure this", or between dev-research and dev-create-plan.
Execute an implementation plan from docs/<feature-name>/PLAN.md — tick checkboxes, commit each phase. Trigger on "implement/execute/continue/resume the plan", "start phase 1", "go" right after a plan was created, or whenever there is a PLAN.md to build, even if the user never says "plan".
Run an autonomous plan → implement → review loop for a feature, iterating until the code review passes and pausing for approval before pushing. Use on "loop on this", "keep going until it passes review", "autonomous dev loop", "plan implement and review", or a self-correcting agent workflow.
| name | dev-perf |
| description | Profile, optimize, and benchmark performance — measure baseline first, find the real bottleneck, optimize one thing at a time, prove it with numbers. Use on "it's slow", "optimize this", "improve performance", "reduce latency", "profile this", or shared timing/benchmark output. |
| argument-hint | [lite|full|ultra] |
Measure → profile → optimize → verify. Never optimize without a measured baseline.
lite | full | ultra, default lite)Mode is the trailing argument when it is exactly lite, full, or ultra; everything else is the task/feature description. No mode given → lite.
lite (default) — one commit covering every optimization.full — one commit per bottleneck fixed, same branch.ultra — independent candidates benchmarked in parallel worktrees; merge only those clearing the bar.Agree what "fast enough" means: current behaviour, target ("under 200ms"), workload. No target given → ask.
go test -bench=. -benchmem ./... # Go
npx clinic flame -- node server.js # Node/TS
pytest --benchmark-only # Python
hey -n 10000 -c 100 http://localhost:3000/endpoint # HTTP, any stack
Record p50/p95/p99 or ops/sec + memory — an average hides tail latency.
Never optimize on intuition:
go test -bench=BenchmarkFoo -cpuprofile=cpu.prof && go tool pprof -http=:8080 cpu.prof # Go
py-spy record -o flame.svg -- python script.py # Python
perf record -F 99 -g -- <command> # Linux, any language
State it before coding: "Bottleneck: <function>, 73% of CPU. Cause: N+1 query in loop." Trust the profile.
Fix the top bottleneck only; re-measure before the next — earlier fixes often eliminate later ones.
| Bottleneck | Fix |
|---|---|
| N+1 queries | Batch with IN (...) or join; index the join column |
| Missing index | EXPLAIN; index the WHERE/JOIN/ORDER BY column |
| Repeated computation in loop | Hoist or memoize |
| Hot-path allocations | Reuse buffers; pool |
| Per-request serialization | Cache serialized form; faster codec |
| Blocking I/O in async context | Async I/O or worker thread |
| Fetching unused data | Select needed columns; paginate |
Touch only the hot path; keep before/after obvious in the diff; tests still pass. full: re-measure + commit per bottleneck, repeat §3–§6. lite: iterate internally, one commit at the end.
Same benchmark as §2. Before: p50 450ms p99 2100ms 12MB → After: p50 38ms p99 120ms 9MB (-92%/-94%). Improvement <10% → revert, look elsewhere.
Commit hygiene and message style: see the git-safe skill (no Co-authored-by:, git add -u not -A, imperative why-focused subject).
git add -u && git commit -m "perf: <what changed> — p99 2100ms → 120ms" — numbers in every perf commit.
Target, bottleneck (from profiler), fix, before/after/delta, tests status, remaining ("next bottleneck" or "target achieved"). If the target is unreachable without structural change (caching layer, different algorithm), say so plainly.