Pawel HurynandClaude Opus 5
18032bc9f7
Restructure, per the ask that code review be the parent and the other two dimensions its sub-cases: - SKILL.md gains a "one engine, three anchors" section. Correctness is the core and stays inline; performance and security move to their own reference files, loaded only when selected. - references/performance-review.md (new) — a universal, stack-agnostic core (repeated work, growth relationships, retention, copying, contention, amplification) plus the three-part bar for a performance finding. Defers the database/web checklist to /performance-audit-static instead of restating it. - references/security-review.md (new) — trust boundaries and sinks for code with no web surface, and the one rule that INVERTS relative to correctness: attacker-equals-victim refutes a security finding but never a correctness one. Defers the full procedure to /security-audit-static. - Both audit commands now say they are the specialisation behind their sub-case, so the narrow entry points still lead back to the skill. ship-check gains two stages it was missing: - Step 3, correctness review — the pass neither audit performs: logic and state defects that compile clean and pass the suite. - Step 6, independent unsteered review — a fresh session of a second model (Codex or equivalent), given no checklist and no prior findings, with the subject computed from a diff rather than described. Every finding is hand-verified against the code before it enters the packet, since an unsteered reviewer carries no refutation discipline of its own. The packet reports whether it ran clean or did not run at all - those are different signals. Also carries the working-tree edits already in progress: model-and-orchestration guidance on both audits, the OWASP A02/A06/A09 backstop, CSP in the output-encoding bullet, the prompt-injection/agent-abuse bullet, and the Audit Provenance section (now also naming the second model). No version bump - not tested against the benchmark yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G42vsxSKL7je39AsHZ5aJm
3.7 KiB
description, argument-hint
| description | argument-hint |
|---|---|
| Static performance audit of AI-built code — find over-fetching, missing indexes, and caching opportunities, ranked by effort and impact | <repo path or area; defaults to the whole repository> |
/performance-audit-static -- Find What Won't Scale
A focused performance review for AI-built code. Agents optimize for "it works on my seed data," not "it holds at 100× the rows." This command finds the three failure modes that surface as data grows — over-fetching, missing indexes, and absent caching — and ranks fixes by effort and impact.
This is a static review of code and queries, not a load test.
Invocation
/performance-audit-static
/performance-audit-static src/views
Scope
Audit $ARGUMENTS. If empty, review the whole repository, prioritizing list and dashboard views, frequently hit endpoints, and large tables.
Model and orchestration
- Run every subagent on the strongest model available — Fable or Mythos when you have access, otherwise Opus 4.8. Match the effort level of the current session when the surface exposes it.
- Flat fan-out for large scopes. For a big repo, fan out with parallel subagents — one per view/route/table cluster running the three checks below — then rank the merged findings yourself. One level is the target; nest a second only when a cluster is too big for one agent's context. Don't reach for a self-generating workflow.
- Reroutes are unlikely here, but report them if they happen. Unlike the security audit, performance work rarely trips Fable's safety classifiers. If a cluster does get rerouted to Opus 4.8, note it in the report so the reader knows the model mix.
The audit
1. Over-fetch in view payloads
Review components that render list or dashboard views. Identify fields fetched from the database but never used in the frontend, SELECT * on wide tables, missing pagination, absent lazy loading, and redundant loads. Suggest a minimal field set per component or route.
2. Missing or inefficient indexes
Review queries, filters, and RPCs used in production views. Identify missing or inefficient indexes based on sort, filter, and join conditions, focusing on large tables and hot endpoints. Give specific index definitions, not "add an index."
3. Caching opportunities
Review endpoints and data-access patterns for frequently called paths that return static or rarely changing data. Identify where frontend or backend caching helps, and specify the invalidation rule for each — caching without an invalidation plan is a correctness bug in waiting.
Output
Report findings per view, route, or table:
Performance Audit: [scope]
<view / route / table>:
- Finding: <what is slow or wasteful>
- Recommendation: <specific change — field set, index definition, cache + invalidation>
- Effort: Low | Medium | High
- Priority: Low | Medium | High
- Expected effect: <e.g. payload size, query time, load time>
End with what's already efficient (say it explicitly) and what needs runtime profiling to confirm. Optionally write the report to /reports/performance_audit_{timestamp}.md.
Notes
- Rank by impact-per-effort — one missing index on a hot table usually beats ten micro-optimizations.
- Don't flag theoretical inefficiency with no growth path; flag what breaks as rows or traffic scale.
- This command covers performance only. For authorization, injection, and data-exposure risks, use
/security-audit-static. - This is the data-backed-application specialisation of the code-review skill's performance sub-case. For logic and state defects, or for a review across several dimensions at once, use
/pm-ai-shipping:code-review. - For an end-to-end pass with documentation and a shipping packet, use
/ship-check.