Prompt Library
These are session-scoped starting points, not durable truth. Fill the <placeholders>, paste into Claude Code (plan mode first for anything that touches architecture or more than a handful of files), then evaluate the output against the criteria on each entry. If you find yourself re-pasting the same constraints twice, escalate them into a file — see Prompts vs Specs.
How to pick a prompt
| You need to… | Start here |
|---|---|
| Start a project, clarify product, plan architecture, decompose work | Project & Planning |
| Design schema, API, UI, ADRs, threat model | Design |
| Implement a feature, backend, UI, walking skeleton | Implementation |
| Review, test, attack, fix types/lint | Quality |
| Debug, refactor, migrate, understand legacy | Maintenance |
| Docs sync, deploy, CI/CD, runbooks, observability | Operations |
| Multi-agent briefs, handoffs, recover from bad output | Agent Management |
Match the job, not the tool. "Write some code" is almost always Implementation or Maintenance; "is this safe to ship?" is Quality or Operations.
How to fill inputs
- Replace every
<angle bracket>with a concrete value — file paths, branch names, acceptance criteria, out-of-scope lists. Leaving a placeholder is worse than a weak prompt: the agent invents a confident-looking fill. - Prefer paths over adjectives.
Follow src/routes/invoices.tsbeats "idiomatic Express." - Paste or
@-reference the real files Claude Code should read. Don't summarize what the agent can open. - Keep durable decisions out of the prompt body when they already live in
CLAUDE.md, a spec, or an ADR — point at those files instead. See Prompt Anatomy.
How to evaluate
Each entry has an Evaluate section. Use it as a gate before you accept the diff or continue the session. Minimum bar for any prompt:
- [ ] Output matches the Expected output shape (not a surprise artifact type)
- [ ] Scope stayed inside the stated files / non-goals
- [ ] Ambiguities were surfaced, not silently resolved
- [ ] You can name the acceptance criteria that are still unmet
If evaluation fails, don't "nudge" with a vague follow-up — use Recover from bad output or open a fresh session with a tighter prompt.
When to customize
Customize when the stock prompt's assumptions don't match your stack, risk, or team process. Keep the structure (context → behavior → constraints → acceptance → out of scope); swap the domain details. Do not customize by deleting constraints to "let the agent be creative" — that reintroduces the six-silent-decisions problem.
Escalate to a committed spec when: the task spans more than one session, another human will pick it up, or the acceptance criteria are load-bearing for production. Prompts stay as pointers; specs carry truth (Specs over Prompts).
Categories
| Category | What it's for |
|---|---|
| Project & Planning | Init, clarification, research, decomposition, handoff |
| Design | Schema, API, UI, ADRs, options, threat model |
| Implementation | Feature/backend/UI build patterns that constrain scope |
| Quality | Review, security, perf, tests, adversarial attack |
| Maintenance | Debug, debt, refactor-with-frozen-behavior, migration |
| Operations | Docs, deploy, CI/CD, release, runbook, readiness |
| Agent Management | Multi-agent briefs, resets, recovery, reconciliation |
Related
- Prompt Anatomy — the structure every library entry assumes
- Prompts vs Specs — when to stop prompting and write a file
- Control Techniques — plan mode, permissions, and session hygiene
- Workflows — full playbooks that embed these prompts end-to-end
- Agent Roles — when one prompt should become two agents