Prompts rebuilt for production, not for likes.

I'm building an MVP: [one-line product description].
Stack: [e.g. Next.js 15 + Supabase + Vercel]. Expected initial load: [e.g. <1k users].

Step 1 - Before writing any code, ask me up to 5 clarifying questions about
scope, then propose the system architecture, file structure, DB schema, and
API endpoints as a plan. Wait for my approval.

Step 2 - After approval, build feature by feature, not all at once.
Start with [auth / core feature].

Constraints:
- Optimize for shipping fast, not for hypothetical scale. Flag (don't build)
  anything that would need rework at 100k users.
- Production basics only: env vars, error handling, input validation.

Audit this codebase like a senior engineer joining the team. Read the actual
code - do not guess from file names.

Phase 1 (report only, no code changes):
Write your findings to AUDIT.md with:
- Architecture overview and data flow
- Issues found, each with file:line references, severity
  (Critical/High/Medium/Low), and why it matters
- Duplicate logic, perf bottlenecks, scalability and maintainability risks

Phase 2 (only after I review AUDIT.md):
We'll pick issues together and fix them one at a time, each on its own
commit, with existing tests passing before and after. If test coverage is
missing for code you want to refactor, write characterization tests first.

Debug this issue like it's a production incident.

Evidence:
- Error/symptom: [paste exact error message or describe behavior]
- When it happens: [steps to reproduce / frequency]
- Logs/stack trace: [paste]
- Recent changes: [git log or "unknown"]

Process:
1. Reproduce or trace the failure path through the actual code before
   proposing anything.
2. State the root cause with file:line evidence. If you can't confirm it,
   say what you'd need to check - do not guess.
3. Propose the minimal safe fix first, then optionally a more robust
   long-term fix as a separate suggestion.
4. Write a regression test that fails before the fix and passes after.
5. List edge cases the fix does and does not cover.

Optimize performance, measurement-first.

Context: [what's slow - page, endpoint, build, query] with
[numbers if I have them: LCP, response time, bundle size].

Process:
1. Identify how to measure the problem (profiler, Lighthouse,
   EXPLAIN ANALYZE, bundle analyzer). Run or ask me to run the
   measurement first.
2. Rank bottlenecks by measured impact - fix the biggest one first.
3. Apply one optimization at a time, re-measure, and report
   before/after numbers.
4. Do not micro-optimize code that isn't in the hot path. Skip anything
   with <5% impact.
5. Note trade-offs (memory, complexity, readability) for each change.

My priority order: [e.g. 1. page load, 2. server cost, 3. memory].

Refactor this codebase incrementally and safely.

Rules:
1. Work on a new branch. Never refactor on main.
2. Before touching any module, confirm it has test coverage. If not, write
   characterization tests that lock in current behavior first.
3. Propose the target folder structure and module boundaries as a plan -
   wait for my approval before moving files.
4. Refactor one module at a time. After each: run the full test suite, then
   commit with a message describing the structural change.
5. Zero behavior changes. If you find a bug mid-refactor, note it in
   BUGS.md - don't fix it in the same commit.
6. At the end, summarize what moved where and why in REFACTOR_NOTES.md.

Design the backend for: [product description].

Real constraints:
- Traffic: [e.g. 500 req/min at launch, maybe 10x in a year]
- Budget: [e.g. <$50/month infra]
- Team: [e.g. solo dev - must be operable by one person]
- Stack preference: [e.g. Node/Postgres on Railway, or serverless]

Deliver:
1. Architecture + data flow, sized for the constraints above - not for a
   hypothetical unicorn. Explicitly call out what I'm deliberately NOT
   building yet and what the migration path is when I outgrow it.
2. API design and DB schema.
3. Caching only if a specific measured need justifies it - otherwise say
   "not yet, add when X."
4. Implementation, one component at a time, starting with [core component].

Build production-grade UI components.

Stack: [React 19 / Next.js, Tailwind v4, framework-specific notes]
Design system: [tokens, fonts, spacing scale - or point to CLAUDE.md]

For each component:
1. Props API first (TypeScript interface with JSDoc) - show me before
   implementing.
2. Handle loading, empty, error, and success states explicitly.
3. Accessibility to WCAG 2.1 AA: semantic HTML, keyboard navigation, focus
   management, ARIA only where semantics fall short. Test keyboard-only.
4. Mobile-first responsive; test at 360px, 768px, 1280px.
5. Include a usage example and note any composition patterns.

Start with: [component name]. Match the visual language of
[reference/existing components] - don't invent a new style per component.

Security audit, report first - do not modify code yet.

Scope: [whole repo / specific area, e.g. auth + payment flow]

Audit against OWASP Top 10, plus specifically check:
- Secrets/keys committed to the repo or exposed client-side (check .env
  handling, NEXT_PUBLIC_ vars, git history if possible)
- Auth: session handling, token expiry, password reset flow, authorization
  checks on every protected route/endpoint (not just UI hiding)
- Input validation and injection (SQL/NoSQL, XSS, SSRF) with file:line
  evidence
- Dependency vulnerabilities (suggest running npm audit / equivalent)
- Sensitive data in logs, error messages, or API responses

Output SECURITY_AUDIT.md: each finding with severity
(Critical/High/Medium/Low), the attack scenario in one sentence, affected
file:line, and the recommended fix.

After I review, we fix Critical/High items one at a time with me testing
auth flows after each change.

Prepare this app for production deployment.

Target platform: [Vercel / Railway / AWS / VPS - pick one]
App type: [Next.js site / Node API / etc.]
Scale reality: [e.g. small client site, <10k visits/month]

Deliver, matched to that platform (no Kubernetes unless the scale genuinely
demands it):
1. Deployment checklist: env vars, secrets management, domains/DNS, HTTPS
2. CI/CD: GitHub Actions that runs lint + tests + build on PR, deploys on
   merge to main - write the actual workflow file
3. Monitoring appropriate to the platform: error tracking
   ([Sentry/etc.]), uptime check, and what alerts I should actually get
4. Rollback plan: how I undo a bad deploy in under 5 minutes
5. A "day 2" list: what to add only when traffic/revenue justifies it,
   with the trigger for each