Claude Code Prompts

Claude Code is the most powerful agentic coding tool of 2026 — but most people still prompt it like a chatbot. The prompts below treat Claude Code as a junior pair with a senior's knowledge: contracts that stop it from patching before understanding, scaffolds that produce runnable SaaS skeletons in one shot, and debugging workflows that isolate root causes instead of guessing. Every prompt is copy-ready: open it, paste it, replace the angle-bracket placeholders.

Start with the scene pages if you know what you're doing here: debugging prompts for bugs, SaaS MVP prompts for building, code review prompts before you merge. New prompts are added every week.

Act as my senior debugging partner. I will paste an error message and the relevant code. Do NOT suggest a fix yet. Instead: (1) restate the failure precisely in one sentence; (2) list the top 3 hypotheses for the root cause, ranked by likelihood, each with a one-line reason; (3) for each hypothesis, propose the cheapest possible experiment that would confirm or kill it. Wait for my experiment results before we move to fixing.

Below is a bug report and the suspected module. Produce a minimal standalone reproduction: the smallest possible file(s) and steps that trigger the bug with no external dependencies. If you cannot reproduce it logically, tell me exactly what information is missing before writing any code.

Here are application logs from a failed session. Do a structured triage: (1) timeline of significant events; (2) the first anomaly in the timeline and why it is anomalous; (3) which of ERROR/WARN lines are symptoms vs. causes; (4) the single most likely root cause and what log line I should add next to prove it. Keep each section under 5 bullets.

This feature worked before and is broken now. Walk a git-bisect-style investigation with me: (1) ask me for the last known-good commit and the first known-bad commit (or help me find them); (2) list the commits in that range grouped by subsystem; (3) identify the 3 most suspicious commits and why; (4) propose the bisect test we should run at each step. Do not modify code until we have isolated the commit.

For every bug I give you, follow this contract: PHASE 1 — explain the bug mechanism in plain language, including why the code was ever written this way (what assumption broke). PHASE 2 — propose at least two fixes: a minimal safe patch and a proper structural fix, with trade-offs. PHASE 3 — only after I choose, implement it, and add one regression test that fails on the old code. Never skip Phase 1 even if the fix seems obvious.

The bug only appears intermittently. Assume a concurrency cause until proven otherwise. (1) Map every async boundary in the suspect flow (awaits, timers, event handlers, network callbacks) in order; (2) mark each pair of operations whose order is NOT guaranteed; (3) for each unguaranteed pair, describe the exact interleaving that would produce the symptom; (4) suggest the minimal logging or assertion that would catch the interleaving in the act.

I will describe a product idea. Before writing any code, return: (1) the single core user journey in 5 steps or fewer; (2) a feature cut-list — everything NOT needed for launch, each with a one-line reason it can wait; (3) the riskiest assumption the MVP must test; (4) a 2-week build plan where each day ends in something demoable. Challenge my scope aggressively; if a feature does not serve the core journey or the riskiest assumption, cut it.

Scaffold a minimal SaaS with Next.js (App Router, TypeScript, Tailwind). Requirements: (1) Supabase auth (email magic link); (2) a protected /app page that reads the session server-side; (3) Stripe Checkout with one $9/mo plan, webhook handler that flips users.paid in Supabase; (4) a landing page with hero, 3 benefits, pricing, FAQ. Generate clean file-by-file, no placeholder comments, every file complete and runnable. Explain nothing except choices you had to make.

Design the Supabase/Postgres schema for this app: <describe app>. Deliver: (1) tables with columns, types and FKs; (2) row-level-security policies for 'users see only their own data' on every table, written as actual SQL; (3) indexes for the 3 most likely query patterns; (4) what you deliberately did NOT normalize and why. Flag any table where a wrong RLS policy would leak data across tenants.

Write landing page copy for <product> targeting <audience>. Structure: (1) headline under 10 words stating the outcome, not the technology; (2) subheadline handling the #1 objection; (3) 3 benefit blocks in 'verb the outcome' form, no jargon; (4) 5 FAQ questions that are actually objections in disguise, with answers; (5) one CTA line repeated at top and bottom. Tone: plain English a smart 12-year-old understands. No hype words like revolutionary, game-changing, unleash.

Generate seed data for this schema: <schema>. Include: 2 normal rows per table; then 1 row each for the edge cases — empty optional fields, unicode names, 10KB text field, dates at min/max bounds, a soft-deleted row, and a row that violates no constraint but 'looks wrong' to a human. Explain in one line per edge row what UI bug it is designed to expose.

Audit this codebase as if we launch tomorrow. Report only, no fixes yet: (1) every place an unhandled error reaches the user as a crash or blank page; (2) missing input validation on any write path; (3) obvious N+1 or missing-index queries on list endpoints; (4) any secret that could leak client-side; (5) the 3 fixes I should do before launch and the 3 that can wait a week. Rank by 'how bad it looks to a first-time visitor'.

Review this diff as a skeptical senior engineer who has been paged at 3am because of 'harmless' changes. Check in order, stop at first category with findings: (1) correctness — what breaks at the boundaries: empty, null, huge, concurrent, offline; (2) failure behavior — what happens when the DB/network/dependency is down; (3) security — injection, auth bypass, secrets in logs, tenant leakage; (4) readability — names that lie, dead code. Per finding: file:line, severity (blocker/should-fix/nit), one-line problem, one-line fix. No praise, no summary.

Security review only, this diff. Check every input path: where does user-controllable data enter, and where does it end up (query, template, shell, redirect, file path, log)? For each, name the injection class that applies and whether the existing escaping/validation actually blocks it. Also: auth checks on every new route, tenant isolation on every new query, secrets handling, error messages that leak internals. Output a table: location, risk, evidence, fix. If you find nothing in a category, say 'checked, clean' — do not pad.

This diff is functionally done. Now review it for the next reader only: (1) names that mislead more than they explain; (2) comments that narrate the code instead of explaining why; (3) nesting deeper than 3 levels that could be early-returns; (4) functions doing two jobs; (5) changes unrelated to the stated purpose (should be a separate commit). Nit-level is welcome here — but every suggestion must come with the one-line rewrite.