Pawel Huryn
8202bdd7f1
New - pm-ai-shipping (9th plugin) — AI Shipping Kit: document a vibe-coded app, audit security/performance against intended behavior, map test coverage, and compile a reviewer-ready shipping packet (2 skills, 5 commands). - pm-execution: strategy-red-team skill + /red-team-prd command (now 16 skills, 11 commands). Changed - Bump all versions 1.0.1 -> 2.0.0 (marketplace.json + all 9 plugin.json) in lockstep. - README: new plugins.png hero + examples.png in "How It Works"; counts updated to 9 plugins / 68 skills / 42 commands across tagline, install block, and per-plugin sections. - CLAUDE.md: 9-plugin structure, plugin table, and version note updated. Validator: 9 plugins, 68 skills, 42 commands, 110 components, 0 warnings. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.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.
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. - For an end-to-end pass with documentation and a shipping packet, use
/ship-check.