Claude Code 74 words
Systematic Root-Cause Debugging
Stop Claude from jumping to patches before the real cause is confirmed.
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.
Claude Code 45 words
Minimal Reproduction Builder
Shrink flaky bugs to a reproducible test case before 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.
Claude Code 62 words
Log Triage Pass
Turn a wall of logs into a causal story.
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.
Claude Code 72 words
Regression Hunter
For 'it used to work' bugs — isolate the breaking change first.
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.
Claude Code 80 words
Explain-Then-Fix Contract
Enforces understanding before patching — set it once per session.
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.
Claude Code 69 words
Async / Race Condition Isolation
For heisenbugs that vanish under the debugger.
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.
Claude Code 79 words
Ruthless MVP Scope Cutter
Run this before any scaffolding prompt.
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.
Claude Code 70 words
Next.js + Supabase + Stripe Scaffold
The classic paid-SaaS skeleton in one shot.
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.
Claude Code 65 words
Schema Design with RLS in Mind
Multi-tenant safety from day one, not as an afterthought.
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.
Claude Code 72 words
Landing Page Copy Generator
Copy structure follows how people actually scan landing pages.
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.
Claude Code 65 words
Seed Data With Edge Cases
Test data that finds the bugs demo users always find first.
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.
Claude Code 79 words
Launch-Day Hardening Pass
Pre-launch checklist driven by visitor perception, not perfection.
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'.
Cursor 110 words
Frontend Project .cursorrules
Drop into .cursorrules at repo root — Cursor applies it to every request.
# Project Rules
- Stack: React 18 + TypeScript + Tailwind CSS + Vite
- All components are function components with explicit prop types; no default exports for components
- Tailwind first: no inline style attributes, no CSS files unless animating
- Co-locate tests as Component.test.tsx using Vitest + Testing Library
- Naming: PascalCase components, camelCase hooks (use* prefix), files match their export
- Prefer composition over prop-drilling; context only for truly global state
- Every user-facing string that will be translated goes through the t() helper
- Accessibility: interactive elements need visible focus states and aria-labels when icon-only
- Do not add new dependencies without stating what they replace
Cursor 97 words
Python Backend .cursorrules
Keeps Cursor from dumping logic into route handlers.
# Project Rules
- Python 3.12, FastAPI, SQLAlchemy 2.0 async, Postgres
- Type hints everywhere; mypy strict must pass
- Endpoints: thin routers -> service layer -> repositories; no business logic in routers
- Pydantic v2 models for all request/response shapes; never return ORM objects directly
- Migrations via Alembic only; never issue raw DDL
- Every DB write happens inside a transaction the service layer owns
- Tests: pytest with async fixtures; a bug fix is not done until it has a failing-first test
- Docstrings only on public service functions, Google style, under 5 lines
Cursor 101 words
Code-Review Enforcer Rules
Turns 'review my code' from vibes into a fixed checklist.
# Review Rules
When I ask for a review, check in this order and stop at the first category with findings:
1. Correctness: does it do what the surrounding code expects? Any edge case that errors silently?
2. Security: injection, auth bypass, secrets in code or logs, missing tenant isolation
3. Failure behavior: what happens when the network/db/dependency is down?
4. Readability: names that lie, dead code, magic numbers
5. Only then style, and only if it contradicts project conventions
Report format per finding: file:line, severity (blocker/should-fix/nit), one-sentence problem, one-sentence suggested fix. No praise, no summary of what the code does.
Cursor 92 words
Small-Commit Contract Rules
Prevents the 40-file mystery PR that can't be reviewed.
# Workflow Rules
- Work in steps small enough that each step compiles and passes tests
- Before editing more than 3 files for one task, present the plan as a file list and wait
- After every logical unit, show me the diff summary and run the test suite
- Commit messages: imperative mood, under 72 chars, body explains WHY not WHAT
- Never mix refactoring and feature changes in the same commit
- If a change breaks a test, fixing the test is part of the change, not a follow-up
Lovable 92 words
SaaS Landing Page in One Prompt
The full page structure Lovable builds best.
Build a landing page for <product>, a <one-line description> for <audience>. Sections: sticky nav with logo, 3 links and a CTA button; hero with headline '<your headline>', subheadline and primary CTA; social proof row with 3 short quotes; 3 feature cards each with icon, title, 2-line description; screenshot placeholder section; 3-tier pricing with the middle tier highlighted 'Most popular'; FAQ accordion with 5 items; footer with 4 columns. Style: clean SaaS, generous whitespace, rounded-xl cards, subtle shadows, one accent color <hex>. Mobile-first, responsive at 375px. No lorem ipsum — write real copy.
Lovable 91 words
Protected Dashboard with Supabase Auth
Auth + shell structure — the base of most Lovable SaaS builds.
Create an app with Supabase authentication: (1) a login page with email magic-link; (2) after login, a dashboard page with a sidebar (Dashboard, Settings, Billing) and a top bar showing the user's email and avatar initials; (3) dashboard body: 4 stat cards, one line chart placeholder, and a recent-activity table with 5 rows; (4) unauthenticated visits redirect to login; (5) a Settings page where the user can update their display name in the profiles table. Use Supabase JS v2, store the session with @supabase/ssr, and protect routes in a layout component.
Lovable 95 words
Waitlist Page with Referral Count
Pre-launch page that grows itself via referral positions.
Build a waitlist page for <product>: (1) hero with headline, one-line pitch and an email input + 'Join waitlist' button; (2) on submit, store the email in a Supabase 'waitlist' table (email, referral_code, referred_by, created_at) and show success state with the person's position number; (3) each signup gets a referral code; show 'You're #<position> — invite friends to move up' with a copyable invite link (?ref=CODE); (4) if the URL has ?ref=, capture it into the form submission; (5) a simple counter under the form showing total signups. Anti-abuse: validate email format, ignore duplicate submissions.
Lovable 90 words
Pricing Page with Monthly/Yearly Toggle
The toggle + comparison table is what Lovable reliably nails.
Build a pricing page for <product> with 3 tiers (<names>). Include: (1) a monthly/yearly toggle where yearly shows '2 months free' and recalculates prices; (2) each tier card: name, one-line audience fit, price, 6-8 feature rows with check icons, CTA button (middle tier highlighted, labeled 'Most popular'); (3) below cards, a feature-comparison table with 8 rows and check/dash cells; (4) an FAQ with 4 pricing objections; (5) a trust line under the CTAs: '14-day refund. No card required for trial.' Style consistent with a clean SaaS look, mobile stacked layout.
Jev 113 words
Support Ticket Triage (One Call, Three Answers)
The pattern from TypeSafe's own docs — all three questions answered in one ~300ms call.
Task: route and grade every inbound support ticket before a human sees it.
state = {
ticket: { subject: "...", body: "..." },
account: { plan: "pro", age_days: 210 }
}
questions:
- department: Choice("Which team should handle this")
billing: "Payment, subscription or refund issues"
technical: "Bugs, integrations or broken features"
success: "How-to questions and account help"
other: "Anything that fits none of the above"
- frustration: Score("How frustrated the customer appears")
["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"]
- churn_risk_now: Noul("The message signals intent to cancel right now")
Routing rule (confidence-gated): if department.confidence < 0.5, queue for a human triager.
If churn_risk_now.noul > 0.7, escalate regardless of department.
Jev 85 words
Content Gate with Asymmetric Error Costs
Encodes your error economics directly into the routing rule.
state = { content: { title, body }, author: { report_count } }
questions:
- violates_policy: Noul("Contains harassment, doxxing or illegal solicitation")
- borderline: Noul("A careful human reviewer would hesitate on this one")
- action: Choice("What to do with this content")
approve: "Clearly fine — publish"
queue_human: "Uncertain enough that a human should look"
reject: "Clearly violating — remove"
Rule: reject only when violates_policy.noul > 0.8 AND borderline.noul < 0.3.
A false rejection costs 10x a false approval — when in doubt, queue_human, never reject.
Jev 91 words
Lead Qualification as Composite Questions
Official best practice: score each axis independently, weight them in code.
state = { lead: { company_size, signup_source, pages_visited_7d, trial_features_used } }
questions:
- icp_fit: Score("How well the company matches our ideal customer profile")
["Outside ICP", "Adjacent market", "Core ICP"]
- activation: Score("How engaged the account was during trial")
["Signed up only", "Explored lightly", "Used the core feature repeatedly"]
- handoff: Choice("Next action")
sdr_call: "Worth a human call this week"
nurture: "Keep in the email sequence"
other: "Not enough signal yet"
Combine in code, not in the model: handoff = sdr_call is respected only when
icp_fit.score >= 1.5 AND handoff.confidence > 0.6.
Jev 95 words
Enum-Only Extraction with "not_stated"
Jev is unreliable at counting and date math; enumeration sidesteps both.
state = { raw: { category_text, price_text, date_text } }
questions:
- category: Choice("Best category for this product")
apparel / electronics / home / beauty / other
- currency: Choice("Currency in price_text")
USD / EUR / GBP / not_stated
- launch_month: Choice("Month mentioned in date_text")
jan ... dec / not_stated
- needs_review: Noul("Any field is ambiguous enough to need a human check")
Per the docs: never ask Jev to parse free-form dates or do arithmetic — enumerate
the options (always including "not_stated") and let it pick. needs_review > 0.5
routes the row to a human.
Jev 65 words
Search Reranking on a Budget
Filter 20 search hits down to the 3 worth an LLM's attention.
state = { query: "the user's original question", candidate: { title, snippet } }
questions:
- relevant: Noul("The candidate page actually answers this query")
- credible: Noul("The source looks authoritative rather than spam")
Run once per candidate. Keep results with relevant > 0.6 AND credible > 0.5,
drop the rest before anything expensive sees them (output tokens are free;
input is ~$0.04 per million tokens).
Jev 81 words
Tool-Call Safety Gate for Coding Agents
A guardrail that's faster and cheaper than a second LLM reviewing the call.
state = { plan: "the agent's stated plan", tool_call: "bash: rm -rf ./data", diff: "..." }
questions:
- irreversible: Noul("This action destroys data or state that cannot be restored")
- off_task: Noul("The action is unrelated to the stated plan")
- hidden_scope: Noul("The command touches files or services outside the workspace")
Rule: block on irreversible OR hidden_scope; ask the user to confirm on off_task.
Questions like these answer in ~250ms — cheap enough to run before every
bash/write call (the "pi-warden" pattern).
Jev 69 words
Difficulty-Based Model Router
Pay frontier prices only for prompts that actually need a frontier model.
state = { prompt: "the incoming user prompt" }
questions:
- difficulty: Score("How hard this prompt is for a small model")
["Trivial FAQ", "Needs real reasoning", "Frontier-level"]
- needs_tools: Noul("Answering requires fresh data: search or API calls")
Route in code: difficulty < 1 -> cheap model; 1-2 -> mid model;
> 2 or needs_tools -> frontier model with tools attached.
Vercel AI Gateway ships this routing pattern natively now.
Jev 84 words
Citation Reality Check
For AI-generated content that must cite real sources.
state = { claim: "the sentence being verified", source: { quote: "verbatim text from the page" } }
questions:
- relation: Choice("Relationship between the quote and the claim")
supports: "The quote directly backs the claim"
contradicts: "The quote states the opposite"
unrelated: "The quote is real but about something else"
- out_of_context: Noul("The quote is technically true but misleading as cited")
This catches the failure mode string matching misses: a citation that exists,
loads fine, and still doesn't say what you claim it says.
v0 75 words
SaaS Landing Page, shadcn Style
v0's sweet spot: full pages with the exact component vocabulary it knows.
Build a landing page for <product>, a <one-line description> for <audience>. Use Next.js + Tailwind + shadcn/ui. Sections: sticky nav (logo, 3 links, CTA); hero with headline '<headline>', subheadline, primary and secondary CTA; logo strip; 3 feature cards with lucide icons; product screenshot placeholder in a browser frame; 3-tier pricing (middle highlighted 'Most popular'); 5-question FAQ accordion; footer with 4 columns. Dark mode support, mobile-first, subtle animations only. No lorem ipsum — write real copy.
v0 69 words
Analytics Dashboard Skeleton
Structure-complete dashboard you can wire to real data after.
Build a dashboard page with shadcn/ui: left sidebar (collapsible, 5 nav items with icons); top bar with breadcrumb, search input and user avatar dropdown; content area with 4 stat cards (label, value, +x% trend badge); one area chart placeholder (recharts) with a 7d/30d/90d range toggle; one recent-events table with status badges and pagination. Dark mode, responsive: sidebar becomes a drawer on mobile. Fill with realistic sample data, no placeholders.
v0 68 words
Pricing Page with Toggle
Specify real prices — v0 fills gaps with believable-looking wrong ones.
Build a pricing page for <product>: monthly/yearly toggle (yearly shows '2 months free'); 3 tier cards — name, audience fit line, price, 7 feature rows with check icons, CTA (middle tier highlighted + 'Most popular' badge); comparison table with 8 rows below; 5-question pricing FAQ; trust line '14-day refund, no card required'. Use shadcn Card, Badge and Table components. Prices: <list yours>. Mobile: cards stack, table scrolls horizontally.
v0 62 words
Waitlist Form with Validation & Success State
Small page, but forces v0 to handle states, not just looks.
Build a waitlist section: centered card with headline, one-line pitch, email input + submit button (shadcn Input + Button). Client-side validation (valid email required, inline error text); on submit show a success state replacing the form: check icon, 'You're #<n> on the list', and a copyable referral link (?ref=). Include a subtle 'we never spam' microcopy line. Keep it dependency-free beyond shadcn.
Bolt 65 words
Full-Stack CRUD MVP in One Shot
Bolt's differentiator: the whole stack runs in one browser sandbox.
Build a full-stack <resource> tracker (e.g. expenses, tasks, clients): React frontend with list view, create/edit modal and delete confirm; Express + SQLite backend with REST CRUD endpoints; simple stats row on top (total, count, latest). Seed 5 demo rows. Run entirely in-browser, no external services. Keep files small and the code boring — this is an MVP to validate the workflow, not a portfolio piece.
Bolt 60 words
Admin Table with Search, Filter, Pagination
The internal-tool pattern every company needs and nobody wants to build.
Build an internal admin page for managing <resource>: data table with search box, a status filter dropdown, column sorting, 10-per-page pagination and row count display; each row has Edit (opens a side drawer form) and Archive (with confirm). Header shows totals per status. Use mock data of 30 rows with realistic values. Prioritize desktop layout, keyboard-friendly (Enter saves, Esc cancels).
Bolt 52 words
Mobile-First PWA Starter
Bolt handles the manifest/service-worker plumbing well.
Build a mobile-first habit tracker PWA: bottom tab navigation (Today, Habits, Stats); Today view with checkable habit cards and a streak flame per habit; Habits view with add/edit/delete; Stats view with a simple 7-day completion bar chart. Installable (manifest + icons), works offline with local storage persistence. Dark mode default. No backend.
Bolt 65 words
REST API Prototype with Docs Page
The docs page makes the prototype demo itself.
Build an Express REST API for <resource> with: CRUD endpoints, input validation returning proper 400s, 404 for missing ids, CORS enabled; plus a single-page docs view at '/' listing every endpoint with method, path, params, and a 'Try it' button that fires the request and shows the JSON response. Seed sample data. This prototype is for showing a client tomorrow — make error messages human-readable.
Windsurf 107 words
Project .windsurfrules Template
Windsurf reads .windsurfrules on every Cascade interaction — set once, applies everywhere.
# Project Rules
- Stack: <your stack — e.g. Next.js 15 + TypeScript + Tailwind + Postgres>
- All new code must type-check and lint clean before you report done
- Prefer editing existing files over creating new ones; never create a file without stating why
- Tests colocated as *.test.ts, Vitest; every bug fix ships with a failing-first test
- No new dependencies without asking; if a task seems to need one, propose it and wait
- Commits: imperative, under 72 chars; never mix refactor and feature
- When requirements are ambiguous, list the 2 most likely readings and pick the conservative one, noting the choice
Windsurf 79 words
Cascade Feature Workflow: Plan → Build → Verify
Tames Cascade's tendency to sweep through 30 files in one go.
We're building: <feature description>. Follow this workflow strictly:
PLAN — list every file you'll touch and the order; wait for my OK.
BUILD — one file at a time, each step must compile; stop if a step breaks something unexpected and tell me.
VERIFY — run the full test suite plus a manual test script you write for this feature; report results honestly, including what you did NOT test.
Do not skip PLAN even when the feature seems small.
Windsurf 68 words
Behavior-Preserving Refactor Pass
Test-first refactoring — the safe version of 'make this code better'.
Refactor <file or module> with one rule above all: BEHAVIOR MUST NOT CHANGE.
Sequence: (1) list current observable behaviors as test cases and add them BEFORE touching code; (2) run them green; (3) refactor in small commits — rename, extract, dedupe — running tests after each; (4) report the diff summary and any dead code found but not deleted. If a test fails mid-refactor, stop and show me.
Windsurf 67 words
Test Suite Bootstrapper
The 'verify tests can fail' step catches suites that pass vacuously.
Bootstrap tests for <module>: (1) inventory every exported function with a one-line behavior guess; (2) for each, write happy-path + one edge case + one failure case; (3) flag any function you cannot test without mocks and propose the mock design; (4) run the suite and report coverage before/after. Tests must fail meaningfully when the code breaks — verify by temporarily breaking one thing (then restore it).
Claude Code 83 words
Skeptical Senior Review
Severity-ordered checklist, tuned to find what causes incidents.
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.
Claude Code 84 words
Security-Only Pass
Follows the data, not the checklist.
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.
Claude Code 72 words
Pre-Merge Readability Pass
The pass to run when correctness is settled and craft is the goal.
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.