AI Coding Prompt Library

Review the following code as a staff engineer would. For each issue found, categorize as:
- BLOCKER: must fix before merge (security, data loss, broken logic)
- MAJOR: should fix before merge (perf regression, missing error handling, brittle patterns)
- MINOR: nice to fix (style, naming, minor duplication)
- NIT: preference only, skip if you disagree

Be direct. Show the exact line and a concrete fix. No hedging. No praise for what's fine — only call out problems.

Audit this code for security issues. Check for:
- SQL injection, XSS, CSRF, SSRF
- Insecure deserialization
- Hardcoded secrets or credentials
- Auth bypass, IDOR, privilege escalation
- Race conditions in auth or payment flows
- Missing rate limiting on sensitive endpoints
- Overly permissive CORS or CSP

For each issue: line number, severity (Critical/High/Medium/Low), exploitation scenario in 1-2 sentences, exact fix.

Analyze this diff for performance regressions. Flag:
- New N+1 queries
- Sync work in async contexts (or vice versa)
- Unbounded loops, recursion, or memory growth
- New network calls in hot paths
- Removed caching or memoization
- Blocking calls on the main thread

For each finding: severity, expected impact (rough magnitude), and the fix.

Extract the highlighted code into a new function. Requirements:
- Function name reflects intent, not implementation
- Preserve exact behavior — no logic changes
- Type-annotate parameters and return
- Add a test asserting new function produces the same output as before for at least one representative input
- Update the original caller to use the new function
Do not touch any code outside the extracted region.

Rename `OLD_NAME` to `NEW_NAME` across the entire codebase. Requirements:
- Update all references (imports, calls, docstrings)
- Update tests
- Update config files, env vars, and CI if applicable
- Do NOT rename in migration files or vendored code
- Show me the list of files changed before applying

Refactor this callback-based code to use async/await. Requirements:
- Preserve the public API signature if possible; otherwise show me the breaking change first
- Preserve error propagation semantics
- Add tests that verify the async version produces the same outputs
- Don't leak Promises into what was previously a sync path

This bug: [describe the observed behavior + expected behavior]

Do NOT guess at a fix. First:
1. List every hypothesis for the cause, most likely first
2. For each, tell me the ONE piece of evidence that would confirm or eliminate it
3. Suggest the fastest experiment (or grep/log check) to test the top hypothesis

Wait for me to run the experiment and share results before proposing a fix.

This test passes sometimes and fails other times. Investigate the flakiness. Check for:
- Timing / race conditions (setTimeout, Promise.all timing, event ordering)
- Test order dependencies (global state, DB pollution, mock leaks)
- External dependencies (network, filesystem, clock)
- Nondeterministic input (Math.random, Date.now, iteration order)

Once identified, propose a fix that eliminates the flakiness, not just papers over it (no retries, no sleep hacks).

Given the following logs + error trace, help me construct a post-mortem draft:
- Timeline of events (from the logs)
- Immediate cause (what code path broke)
- Contributing factors (what let it happen)
- Detection (how did we find out; how could we find it faster)
- Mitigation (what we did to stop it)
- Prevention (what change prevents recurrence)

Be factual, not blaming. Focus on system failures, not individuals.

Write a README for this project. Structure:
1. One-sentence description (what it is + who it's for)
2. Install (exact commands)
3. Quickstart (5 lines max, working code)
4. Configuration (env vars + files)
5. Common tasks (deploy, test, debug)

Skip marketing fluff. No emoji. No badges. Assume the reader is a competent dev who wants to get started fast.

For each API endpoint in this file, produce:
- Method + path
- Purpose (1 sentence)
- Request body/query schema with example
- Response schema (success + error shapes) with example
- Auth requirements
- Rate limits
- Common errors and their meanings

Format as Markdown with headers. Suitable for embedding in an API reference site.

This function has no tests. Write a test suite covering:
- Happy path (normal expected input)
- Boundary cases (empty, single item, max)
- Invalid input (wrong type, out of range, null)
- Error paths (throws or returns error)

Use [testing framework]. Prefer parameterized/table-driven tests where the same assertion runs for multiple inputs. Don't test implementation details, test behavior.

There's a bug: [describe]. Before fixing it, write ONE test that reliably reproduces the bug. The test should:
- Fail with the current buggy code
- Pass once the bug is fixed
- Have a name that describes the bug behavior, not the fix
- Be self-contained (no external state)

Show me the test first. I'll confirm it fails before we fix the bug.

This query is slow: [query]. Explain:
1. What's likely making it slow (based on the query shape — no `EXPLAIN` yet)
2. What indexes should exist for it to be fast
3. Whether the query can be rewritten more efficiently
4. Whether the schema itself is the problem (denormalize? materialized view?)

Give me the `EXPLAIN` command to run to verify, then propose the fix based on what I share.

I need to [add column / change type / rename / add index] on this table with [N] million rows. Requirements:
- Zero downtime (no long locks)
- Reversible if it fails
- Compatible with the current running code (no breaking changes to callers)
- If the change requires app changes, sketch the multi-step migration path

Write the migration SQL and describe any coordination needed with deploys.

I want to [describe refactor goal]. Do NOT make changes yet. Instead:
1. List every file that will be touched
2. Order the changes so intermediate commits still compile and pass tests
3. Identify any risky steps (breaking changes, data migrations, deploy coordination)
4. Estimate total scope in lines-changed magnitude

Wait for my go-ahead before making any changes.

I don't understand this code. Explain it as if writing a comment for a future developer. Cover:
- What it does (1 sentence)
- Why it exists (what problem it solves)
- How it works, focusing only on the non-obvious parts
- What would break if this code was removed

Skip anything self-evident. Assume the reader knows the language and common patterns.