// prompts

Prompts & Techniques

A working library of reusable prompts and workflow patterns for directing AI coding tools. Battle-tested, copy-pasteable, and grouped by what you're actually trying to do — plan, debug, refactor, review, or set the rules of engagement.

18 Prompts

7 Categories

⌘C Copy & go

Planning

Plan before you code

Planning

prompt

Before writing any code, produce a short implementation plan for this task:

1. Restate the goal in one sentence so we agree on scope.
2. List the files you expect to create or change, with a one-line reason for each.
3. Describe the approach in 3-6 numbered steps.
4. Call out anything ambiguous, risky, or that you'd do differently — and ask me any questions you need answered first.

Do NOT write code yet. Wait for me to approve or correct the plan.

When to use: At the start of any non-trivial task — a new feature, a multi-file change, or anything you cannot fully picture in your head.
Why it works: A cheap plan surfaces wrong assumptions before they become wrong code. Reviewing a 6-line plan costs seconds; reviewing 300 lines of misguided implementation costs the afternoon.

Explain this codebase to me

Planning

prompt

You are onboarding me to this codebase. Without changing any files, give me:

1. The 30-second pitch: what this app does and who uses it.
2. The directory map — top-level folders and what lives in each.
3. The request/data lifecycle: trace one typical action from entry point to response.
4. The 5 files I should read first to be productive, in order, with why.
5. Any conventions, gotchas, or "here be dragons" areas a newcomer would trip on.

Cite real file paths. If you're unsure about something, say so rather than guessing.

When to use: Landing in an unfamiliar repo, inheriting someone else's project, or returning to your own code months later.
Why it works: It turns the agent into a tour guide that has actually read the files, replacing hours of blind clicking with a map and a reading order. The "say so rather than guessing" clause keeps it honest.

Spec writing

Write the spec first

Spec writing

prompt

Before we build anything, let's write a short spec for this feature. Draft it as markdown with these sections, and leave a "TBD — needs decision" marker anywhere you're guessing:

## Goal
What we're building and the problem it solves.

## User stories
"As a <user>, I want <action> so that <outcome>." 3-5 of them.

## Behaviour & rules
The concrete rules: inputs, outputs, edge cases, validation, error states.

## Out of scope
What we are explicitly NOT doing in this pass.

## Acceptance criteria
A checklist I can verify the finished feature against.

Ask me about every TBD before we move on.

When to use: Any feature bigger than a one-liner, especially when requirements live only in your head or a vague ticket.
Why it works: Vague specs produce confidently wrong code. Writing the spec first turns fuzzy intent into a checklist both you and the model build against — and the "out of scope" section is the single best defense against feature creep.

Turn the spec into tests

Spec writing

prompt

Here is the spec / acceptance criteria for the feature:

<PASTE SPEC OR CRITERIA>

Before implementing, write the test cases that prove each acceptance criterion. For each test:
- Name it after the behaviour it checks (not the function name).
- Cover the happy path, the boundaries, and at least one failure/error case.
- Use our existing test framework and conventions — match the style of the tests already in the repo.

Show me the full list of test names first as a checklist, then write the tests. Don't implement the feature yet.

When to use: Right after a spec is agreed and before implementation — turning "what it should do" into executable checks.
Why it works: Tests written from the spec become an objective definition of done. Seeing the test names as a checklist first catches missing cases early, and the model then has a concrete target to make pass instead of a vibe.

Pre-mortem this plan

Spec writing

prompt

Here's the plan we've agreed on:

<PASTE PLAN OR SPEC>

Run a pre-mortem. Imagine it's a month from now and this shipped badly. Tell me:
- The 3 most likely ways it broke or disappointed users.
- Which assumptions in the plan were the riskiest.
- The smallest changes we could make now to de-risk it.

Be blunt. I'd rather hear the uncomfortable version now than discover it in production.

When to use: After a plan looks good but before committing real effort — especially for anything touching data, money, auth, or migrations.
Why it works: Imagining failure as already-happened unlocks concerns that "any risks?" never surfaces. It is the cheapest insurance you can buy on a plan, and it costs one prompt.

Workflow

Tighten scope — one change at a time

Workflow

prompt

Let's make exactly one change at a time. For this step:

- Make ONLY the change we just discussed. Don't refactor unrelated code, rename things, reformat, or "improve" anything I didn't ask for.
- Keep the diff as small as possible.
- After the change, summarise in 2-3 lines what you changed and what I should verify.

If you notice something else worth fixing, add it to a "later" list at the end instead of doing it now.

When to use: Always, but especially when the agent keeps bundling drive-by edits into your change and your diffs are getting noisy and hard to review.
Why it works: Small, single-purpose diffs are reviewable, revertable, and easy to bisect when something breaks. The "later list" gives the model somewhere to put its good ideas without derailing the current step.

Checkpoint, then continue

Workflow

prompt

Before you continue, give me a checkpoint:

- What's DONE so far (be specific — files, behaviours).
- What's left to reach the goal we set.
- Anything that changed your understanding or that you got stuck on.

Then ask me whether to keep going or adjust course. Don't burn through the rest of the task until I confirm.

When to use: Midway through a long task, or any time the agent has been working autonomously for a while and you want to confirm it's still on the rails.
Why it works: Long agent runs drift. A periodic checkpoint catches drift while it's cheap to correct, and re-grounds the model in the agreed goal instead of whatever it has wandered into.

Write the commit message from the diff

Workflow

prompt

Look at the staged changes (the diff) and write a commit message.

- Subject line: imperative mood, under 60 characters, no trailing period. (e.g. "Add retry to feed fetcher")
- Blank line, then a body that explains WHY this change was made and what it affects — not a line-by-line restatement of the diff.
- If it fixes a bug, briefly describe the bug and the root cause.
- Match the style of recent commits in this repo.

Show me the message only. Don't commit.

When to use: Every commit. Especially valuable when you've lost track of everything that went into a change and need an accurate, well-shaped message.
Why it works: The model can read the actual diff, so the message describes what really changed rather than what you remember changing. Asking for the "why" produces history that's useful to future-you instead of noise.

Debugging

Rubber-duck the bug with full context

Debugging

prompt

I have a bug. Here is everything:

WHAT I EXPECTED:
<expected behaviour>

WHAT ACTUALLY HAPPENS:
<actual behaviour, exact symptoms>

HOW TO REPRODUCE:
<steps>

RELEVANT CODE / FILES:
<paste code or point to files>

ERROR OUTPUT / LOGS (verbatim):
<paste exact errors>

WHAT I'VE ALREADY TRIED:
<list>

Don't suggest a fix yet. First, walk through the likely cause step by step and tell me which 1-2 hypotheses you'd investigate first and exactly how you'd confirm each.

When to use: Any bug you can't immediately see the cause of. The act of filling in every section often reveals the answer before you even send it.
Why it works: Most bad debugging help comes from missing context. Giving expected vs. actual, repro steps, verbatim errors, and what you already ruled out lets the model reason instead of guess. Asking for hypotheses before fixes prevents shotgun edits.

Find the root cause, not a band-aid

Debugging

prompt

This bug keeps coming back / we've patched the symptom before:

<DESCRIBE THE BUG AND ANY PAST PATCHES>

I don't want another band-aid. Trace this to its root cause:
1. Explain the actual mechanism — why does this happen, step by step?
2. Show me the specific line(s) where the real problem originates.
3. Propose a fix that addresses the cause, and explain how it prevents the whole class of this bug, not just this instance.
4. Tell me what test would catch a regression.

If you're not confident in the root cause, say what you'd need to log or inspect to be sure.

When to use: Recurring bugs, "we already fixed this", or any time a quick patch feels like it's treating a symptom rather than the disease.
Why it works: It explicitly redirects the model away from the fastest-looking patch toward the mechanism. Requesting a regression test turns the fix into something that stays fixed.

Reduce it to a minimal reproduction

Debugging

prompt

Help me shrink this bug to the smallest possible reproduction.

Here's the failing scenario and code:
<PASTE>

Strip away everything that isn't required to trigger the bug. After each removal, the bug must still reproduce. Give me the smallest standalone snippet (or test) that still fails, and once it's minimal, tell me what that minimal case reveals about the cause.

When to use: Bugs tangled up in a large flow, hard-to-explain behaviour, or anything you might need to file as an issue or hand to a teammate.
Why it works: Shrinking the repro removes confounding variables one at a time; very often the bug becomes obvious the moment the surrounding noise is gone. A minimal case is also the most useful thing to attach to a bug report.

Refactoring

Refactor without changing behaviour

Refactoring

prompt

Refactor this code for clarity WITHOUT changing its behaviour.

<PASTE CODE OR POINT TO FILE>

Rules:
- The public interface and observable behaviour must stay identical.
- Make one category of improvement at a time (e.g. naming, then extraction, then dead-code removal) and tell me which one each step is.
- If tests exist, they must still pass; if they don't, tell me what to check by hand.
- Explain each change in a few words so I can follow the reasoning.

Start by telling me the 2-3 things that most hurt readability here, then refactor those first.

When to use: Code that works but is hard to read or extend, before you build new features on top of it.
Why it works: Pinning behaviour as invariant keeps a "cleanup" from quietly becoming a rewrite with new bugs. Doing one category at a time keeps the diff legible and easy to revert if a step goes wrong.

Pin behaviour before you touch it

Refactoring

prompt

I need to change this code but I'm not confident I understand all of its current behaviour, and there are no tests:

<PASTE CODE OR POINT TO FILE>

Before we change anything, write characterization tests that capture what the code ACTUALLY does right now — including any quirks, even ones that look like bugs. The goal is a safety net, not a judgement on correctness.

List the behaviours you're locking in. Flag anything that looks unintentional so I can decide whether to preserve or fix it later. Don't modify the code yet.

When to use: Before refactoring or extending legacy code that has no tests and behaviour you don't fully trust.
Why it works: Characterization tests freeze current behaviour so any later change that alters it shows up immediately as a failing test. Flagging suspicious quirks separately lets you decide deliberately what to keep versus fix.

Code review

Review this diff like a skeptical senior engineer

Code review

prompt

Review this diff the way a skeptical senior engineer would in a PR. Assume it has problems and find them.

<PASTE DIFF>

Focus on, in priority order:
1. Correctness — bugs, edge cases, off-by-ones, race conditions, broken error handling.
2. Security — injection, auth/authorization gaps, leaked secrets, unsafe input.
3. Failure modes — what happens when inputs are empty, huge, malformed, or the network dies.
4. Clarity — naming, dead code, anything a future reader will misread.

For each issue: file + line, severity (blocker / should-fix / nit), what's wrong, and the fix. Don't praise the code — just find what needs attention. If something is genuinely fine, stay silent on it.

When to use: Before opening a PR, before merging your own AI-written code, or any time something works but you haven't convinced yourself it's actually correct.
Why it works: A neutral "any feedback?" gets you flattery. Casting the model as skeptical and ordering concerns by severity gets you the blocker buried on line 80. Suppressing praise keeps the output dense and actionable.

Security pass on this change

Code review

prompt

Do a focused security review of this code/diff. Ignore style — I only want security issues.

<PASTE CODE OR DIFF>

Check specifically for:
- Untrusted input reaching a sink (SQL, shell, HTML, file paths, eval).
- Authn/authz: can a user reach data or actions they shouldn't?
- Secrets, tokens, or keys in code, logs, or error messages.
- Unsafe defaults, missing validation, or overly broad permissions.
- Dependency or config risks introduced by this change.

For each finding: severity, a concrete exploit scenario in one sentence, and the remediation. If you find nothing in a category, say "no issues found" for it explicitly.

When to use: Anything touching user input, authentication, file/network access, or handling secrets — before it goes live.
Why it works: A dedicated, category-by-category security pass catches what a general review skims over. Requiring an explicit "no issues found" per category prevents silent gaps where the model simply forgot to look.

Rules/System

A solid rules / CLAUDE.md starter

Rules/System

prompt

# Project rules

## What this is
<One or two sentences: what the app does and its current stage (prototype / production).>

## Stack
<Language, framework, package manager, database, deploy target. Be specific with versions where they matter.>

## Commands
- Install: <command>
- Dev server: <command>
- Test: <command>
- Lint / typecheck: <command>
- Build: <command>

## How I want you to work
- Make the smallest change that satisfies the request. Don't refactor or reformat code I didn't ask you to touch.
- Plan non-trivial work before coding and wait for my go-ahead.
- Match the existing style and patterns in nearby files — don't introduce new libraries or conventions without asking.
- After changes, run the relevant tests/typecheck and report the result honestly. Never claim something passes without checking.
- If a request is ambiguous, ask one clarifying question rather than guessing.

## Conventions
- <Naming, file layout, where tests live, error-handling style, anything non-obvious.>

## Don't
- <Files/dirs never to touch (generated code, vendored deps, secrets).>
- <Footguns specific to this project.>

When to use: Set this up once per project. A persistent rules file (CLAUDE.md, .cursorrules, etc.) makes every future session start with shared context instead of re-explaining yourself.
Why it works: The model reloads these rules every session, so good defaults compound. Commands and conventions stop the agent from inventing its own; the "Don't" section prevents the same mistakes from recurring across conversations.

Set the working persona up front

Rules/System

prompt

For this whole session, work like a senior engineer pairing with me on production code:

- Bias toward simple, boring, proven solutions over clever ones.
- Be direct. If I'm about to do something unwise, say so plainly and explain why — don't just agree with me.
- When you're uncertain, say "I'm not sure" and tell me how we'd find out, rather than guessing confidently.
- Never invent APIs, functions, config options, or file paths. If you're not certain something exists, check or flag it.
- Keep responses tight. Show code and reasoning, skip the filler and the cheerleading.

Confirm you've got it in one line, then we'll start.

When to use: At the start of a serious working session, to set tone and standards before any real work begins.
Why it works: A clear persona and explicit anti-sycophancy instruction shift the model from agreeable assistant to candid collaborator. Banning invented APIs up front meaningfully cuts hallucinated calls you'd otherwise debug.

Define "done" before starting

Rules/System

prompt

Before you start, here's the definition of done for this task. Don't tell me it's finished until every box is genuinely true — and if one isn't, say which and why.

- [ ] The feature/fix works for the main case I described.
- [ ] Edge cases and error states are handled, not ignored.
- [ ] Tests are written and actually pass (show me the run output).
- [ ] Typecheck / lint pass with no new warnings.
- [ ] No leftover debug logging, commented-out code, or TODOs you introduced.
- [ ] The change is scoped — no unrelated edits snuck in.

When you believe it's done, walk the checklist and show me the evidence for each box.

When to use: At the start of any task where "looks done" and "is done" tend to diverge — which is most of them.
Why it works: An explicit, verifiable checklist forces the model to confirm rather than assume, and the "show me the evidence" clause is the single best defense against the confident "all tests pass!" that turns out to be untrue.

Got a prompt that earns its keep? Share it in the Discord. Looking for tools or guides instead? Try Tools and Learn.