From quality
Analyze a codebase for performance bottlenecks in full-stack web applications. Use when user says "quality-perf-review", "perf review", "performance review", "find bottlenecks", "optimize performance", "slow code", "performance audit", or "why is my app slow". Interactive workflow that discusses each finding before moving on.
How this skill is triggered — by the user, by Claude, or both
Slash command
/quality:perf-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Analyze a full-stack web application for real performance bottlenecks. Focus on evidence-based issues, not generic suggestions. Interactive workflow that discusses each finding with the user.
Analyze a full-stack web application for real performance bottlenecks. Focus on evidence-based issues, not generic suggestions. Interactive workflow that discusses each finding with the user.
Use this skill when the user requests:
Before analyzing, understand the project:
# Detect project type
ls package.json bun.lockb yarn.lock pnpm-lock.yaml 2>/dev/null
# Check for existing benchmarks
find . -name "*.bench.ts" -o -name "*.benchmark.ts" -o -name "bench.ts" 2>/dev/null
# Check for profiling config
ls .clinic clinic.json 0x.json 2>/dev/null
# Check frontend framework
grep -l "react\|vue\|svelte\|next\|nuxt" package.json 2>/dev/null
Inform the user:
Analyze code for known performance anti-patterns. Check each category based on what's relevant to the project.
Look for:
include/join in ORM queriesSELECT * when only specific columns neededGrep patterns:
- "\.find\(" inside forEach/map/for loops
- "await.*query" inside loops
- "SELECT \*" in raw queries
Look for:
Look for:
Look for:
readFileSync / writeFileSync (sync file ops)Look for:
Look for:
import lodash vs import { map } from 'lodash')# Check bundle size if available
bun build --analyze 2>/dev/null || npx webpack-bundle-analyzer 2>/dev/null
Look for:
useMemo/useCallback for expensive computationskey props or using index as keyLook for:
Look for:
If static analysis is inconclusive, offer to run benchmarks:
Question: "I'd like to run some performance measurements to identify bottlenecks more precisely. May I?"
Options:
- "Yes, run benchmarks" - Execute performance tests
- "No, continue with static analysis" - Skip dynamic analysis
- "Tell me what you'd run first" - Explain before executing
If approved, depending on project type:
For Bun/Node backend:
# Profile with clinic (if available)
npx clinic doctor -- node server.js
# Or use built-in profiler
node --prof server.js
For frontend:
# Measure bundle size
bun build --minify --outdir=dist && du -sh dist/
# Or with webpack
npx webpack-bundle-analyzer stats.json
For each finding, present it interactively:
## Finding [N]: [Title]
**Location:** `file/path.ts:123`
**Category:** [Database/Memory/Bundle/etc.]
**Impact:** [High/Medium/Low] - [explanation of impact]
### The Issue
[Code snippet showing the problem]
### Why This Matters
[Explanation with numbers if possible - e.g., "This query runs N times per request"]
### Proposed Fix
[Code snippet showing the fix]
### Safety Assessment
- **Regression risk:** [Low/Medium] - [explanation]
- **Behavior change:** None / [describe any edge case differences]
- **Test coverage:** [covered by X test / not covered]
- **Reversibility:** [easy to revert / requires migration]
After presenting each finding, ask:
Question: "How would you like to proceed with this finding?"
Options:
- "Apply this fix" - I'll make the change
- "Skip for now" - Move to next finding
- "Tell me more" - Explain in more detail
- "I'll fix it myself" - Note it and move on
After reviewing all findings, provide a summary:
## Performance Review Summary
### Applied Fixes
1. [Finding 1] - [file:line]
2. [Finding 2] - [file:line]
### Skipped/Deferred
1. [Finding 3] - Reason: [user chose to skip / needs more investigation]
### Estimated Impact
- Database queries: X fewer per request
- Bundle size: -Y KB
- Response time: [estimated improvement]
### Recommended Next Steps
1. [Run the test suite to verify no regressions]
2. [Set up performance monitoring for X]
3. [Consider profiling Y in production]
for vs forEach without evidenceBefore suggesting any fix, verify:
If uncertain about safety, present as "potential optimization" requiring user verification rather than a fix to apply.
Bad (N+1):
const users = await db.user.findMany();
for (const user of users) {
const posts = await db.post.findMany({ where: { userId: user.id } });
// ... 100 users = 101 queries
}
Good (single query):
const users = await db.user.findMany({
include: { posts: true }
});
// 1 query with JOIN
Bad (imports entire library):
import _ from 'lodash';
const result = _.map(items, transform);
Good (tree-shakeable):
import { map } from 'lodash-es';
const result = map(items, transform);
Bad (blocks event loop):
app.get('/config', (req, res) => {
const config = fs.readFileSync('./config.json');
res.json(JSON.parse(config));
});
Good (non-blocking):
app.get('/config', async (req, res) => {
const config = await Bun.file('./config.json').json();
res.json(config);
});
npx claudepluginhub zcaceres/skills --plugin qualityFetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.