Skip to content

Prompt library starter

This is a starter library — the smallest useful set of reusable prompt templates, organized by use case and mapped to the named frameworks. Templates use <placeholders in angle brackets>. Replace every placeholder before sending; an unfilled placeholder is the most common cause of low-quality output.

Use the library, then specialize it

Adopt these as a baseline, fork them into your team's wiki, and adapt placeholders to your stack. The framework intentionally keeps the starter set small so teams add their own context without fighting an overgrown default.

The templates below sit on top of the named practices. Each section links back to its parent framework page; if a template's intent is not clear, read the framework page first.

S.C.A.F.F.-shaped prompts

Templates for new work, organized to fill all five S.C.A.F.F. slots — Situation, Context, Action, Foundations, Format. See S.C.A.F.F. for the full pattern.

1. New-feature scaffold

SITUATION
We are adding a new feature to <product / service name>: <one-sentence
summary of the user-facing behavior>. The feature ships behind feature
flag <flag name> and targets <release date>.

CONTEXT
- Repository: <repo name>, language <language>, framework <framework>.
- Relevant existing modules: <module 1>, <module 2>.
- Data model touchpoints: <table / entity names>.
- Current test coverage in this area: <high / medium / low>.

ACTION
Produce <a scaffold / a working implementation / a design proposal> for
the feature. Specifically:
1. <step 1>
2. <step 2>
3. <step 3>

FOUNDATIONS
- Security: validate all inputs at the boundary; do not log secrets;
  authorize the caller against <authz model>.
- Style: follow the existing patterns in <module 1>; match the project's
  linter (<linter name>).
- Risk tier: <Low / Medium / High / Critical> per our risk classification.
- Out of scope: <list explicit non-goals>.

FORMAT
Return the answer as:
1. A short plan (5–8 bullet points) describing the change.
2. The code, organized by file path.
3. A list of follow-up tasks I should consider but you did not implement.

2. Refactor request

SITUATION
The module <path/to/module> has accreted complexity and we want to
reduce it without changing externally observable behavior.

CONTEXT
- Public surface: <list functions / classes that callers depend on>.
- Test coverage: <link / description>.
- Known smells: <e.g. "long parameter lists", "nested conditionals">.
- Constraints: <e.g. "must remain backwards-compatible with v1.x callers">.

ACTION
Propose a refactor that achieves <specific goal — e.g. "reduces
cyclomatic complexity below 10 per function">. Apply the R.E.F.A.C.T.
sequence: Read first, establish missing tests, plan small steps, apply
one at a time.

FOUNDATIONS
- No public-API changes unless explicitly approved.
- Every step must keep the test suite green.
- Prefer extraction over rewriting.

FORMAT
1. Plan: ordered list of safe steps, each with a one-line rationale.
2. For step 1 only: the diff and the tests that prove behavior is
   preserved.
3. Stop. Wait for me to approve step 1 before producing step 2.

3. Test generation

SITUATION
I need additional tests for <function / module / behavior>. Existing
coverage is <gap description>.

CONTEXT
- Test framework: <framework name>.
- Existing test patterns: <link or paste 1-2 representative tests>.
- Behavior under test: <description, including invariants>.
- Known edge cases already covered: <list>.

ACTION
Generate <N> test cases that cover:
- Happy path: <list>.
- Edge cases: <list>.
- Error and failure modes: <list>.
Do not modify the implementation.

FOUNDATIONS
- Tests must be deterministic (no real network, real time, or real
  randomness).
- Each test asserts one behavior.
- Use the project's existing test fixtures rather than introducing new
  patterns.

FORMAT
- Tests grouped by category (happy / edge / error).
- Each test preceded by a one-line comment stating the invariant.
- A short final list of behaviors you considered but did not test, and
  why.

4. Debugging session

SITUATION
I am observing the following defect: <one-sentence symptom>.

CONTEXT
- Reproduction steps: <numbered steps>.
- Expected behavior: <description>.
- Actual behavior: <description>.
- Relevant logs / errors / stack traces: <paste, redacted of secrets>.
- Recent changes that may be relevant: <commit IDs / PRs>.
- Already ruled out: <list — to prevent re-suggestion>.

ACTION
Help me diagnose this defect. Do not propose code changes yet — propose
hypotheses and the evidence each hypothesis predicts.

FOUNDATIONS
- Do not invent functions, file paths, or APIs that I have not shown
  you.
- If a hypothesis requires information you do not have, name the
  information and how I would gather it.

FORMAT
- A ranked list of 3–5 hypotheses, each with: prediction, evidence I
  could collect, and a quick test to discriminate it from the others.
- Stop after the list. Wait for me to share new evidence before
  proposing a fix.

V.E.R.I.F.Y. checklists

Self-validation prompts to apply to AI output, after generation. See V.E.R.I.F.Y..

Self-validation is not sufficient

A model checking its own output will miss the same things it missed the first time. Always pair these prompts with human review and the C.L.E.A.R. protocol — these templates make the human reviewer's job easier; they do not replace the reviewer.

5. Self-validation pass

You produced the following output: <paste output>.

Run the V.E.R.I.F.Y. checklist against your own output and report:

1. INTENT — In one sentence, restate what you were asked to do. If your
   output addresses something different, say so.
2. EXAMINE — List the assumptions you made that were not stated in the
   prompt. For each, mark whether the assumption is safe or risky.
3. RUN — List the test cases that should pass for this output to be
   considered correct. Do not run them; just enumerate them.
4. INSPECT — Identify three specific places this output could fail
   security review (input validation, authz, data exposure, error
   handling, secret handling). Be concrete.
5. FRAME — What does a reviewer need to know that is not visible in the
   diff alone? (Prior decisions, alternatives considered, residual
   risks.)
6. YES/NO — If you were the reviewer, would you approve this on first
   pass? If not, what would you ask to be changed?

Be honest. A clean report on your own output is suspicious.

6. Confabulation check

For the output you just produced, list every:

- Function, class, or module you referenced.
- API, library, or service you called.
- Configuration option, flag, or environment variable you mentioned.
- File path you referenced.

For each item, mark:
- [VERIFIED] if it appears verbatim in the context I provided you.
- [INFERRED] if you derived it from context but did not see it directly.
- [GUESSED] if you produced it without supporting context.

Do not change the output yet. The list itself is what I need.

C.L.E.A.R. review prompts

Prompts a reviewer can use to interrogate an AI-generated change. See C.L.E.A.R..

7. Pull-request interrogation

You are reviewing a pull request that was authored with significant AI
assistance. The diff is attached below.

Apply the C.L.E.A.R. review protocol:

CONTEXT — What problem does this PR solve? Is the problem well-defined?
LOGIC — Walk through the control flow of the new code in plain English.
   Are there branches that look unreachable, or branches that should
   exist but don't?
EDGE CASES — What inputs would break this? Empty? Null? Maximum size?
   Concurrent? Adversarial?
AUTHORSHIP — What part of this looks like it came from a model's
   defaults rather than the team's existing patterns? Flag specifically.
RISK — What is the blast radius if this ships with a defect? Per our
   risk classification, what tier does this code sit at?

Return one section per letter. Do not propose code changes — just
findings.

DIFF:
<paste diff>

8. Reviewer checklist for AI-adjacent merges

This change was authored with AI assistance. Before I approve, answer:

1. Is the intent of the change documented separately from the
   implementation? (Issue link, decision record, design note?)
2. Are tests present and do they cover the behavior, not just the
   implementation?
3. Are inputs validated at the boundary?
4. Is authorization checked at the boundary?
5. Are secrets, tokens, or PII present in any added log line, comment,
   error message, or test fixture?
6. Are there new dependencies? If so, which licenses?
7. Are there new external calls (network, file, database, model)? If
   so, are they timeout-bounded and retried sensibly?
8. Is there a rollback plan if this misbehaves in production?

For each "no", explain why it is acceptable to merge anyway, or what
needs to change.

R.E.F.A.C.T. prompts

Safe-step refactoring templates. See R.E.F.A.C.T..

9. One-step refactor

Apply exactly one R.E.F.A.C.T. step to the code below: <name the step,
e.g. "extract method", "rename for clarity", "introduce parameter object">.

CONSTRAINTS
- The change must be a behavior-preserving refactor only — no logic
  changes, no bug fixes mixed in.
- All existing tests must still pass.
- The diff should be as small as possible.

DELIVERABLES
1. The diff.
2. The reasoning for the change in two sentences.
3. The next R.E.F.A.C.T. step you would take, but do not apply it.

CODE:
<paste code>

10. Test-then-refactor

Before refactoring <module>, I want characterization tests that pin its
current behavior — including any quirks. Do not change the
implementation.

Generate characterization tests that:
- Exercise every public function.
- Capture observable behavior, including edge cases (empty, null,
  large, concurrent if relevant).
- Use only the project's existing test framework and fixtures.

Return:
1. The tests.
2. A list of behaviors you observed that may be defects rather than
   features. Do not "fix" them — just flag them so I can decide.

CODE:
<paste code>

D.O.C.S. prompts

Doc-extraction and -drafting templates. See D.O.C.S..

11. Decision record extraction

From the following thread / chat / change set, extract a Decision Record
in this structure:

- Title
- Context: what problem prompted the decision
- Decision: what we chose
- Alternatives considered: at least two
- Consequences: positive and negative
- Status: proposed | accepted | superseded
- Date

Quote text from the source where possible. Do not invent rationales the
authors did not state. If a slot has no evidence in the source, write
"not stated in source" — do not guess.

SOURCE:
<paste source>

12. Module readme draft

Produce a README for the module at <path>. The README must include:

1. One-sentence purpose.
2. Public surface: the functions, classes, or endpoints other modules
   depend on, with one-line descriptions.
3. Setup or configuration requirements.
4. A minimal usage example.
5. Known limitations.
6. Where to look for tests.

Constraints:
- Cite specific file paths and function names from the code I provide.
- If you cannot determine a section from the code, write "TBD" — do not
  fabricate.

CODE:
<paste code or list of files>

Anti-prompts — patterns to avoid

Do not use these patterns

The following patterns produce sprawling, low-quality output and are routinely linked to the security and quality issues documented in the evidence pack. Reject them in review.

  • "Fix this." No problem statement, no context, no constraints. The model guesses at intent and at the bug; you inherit both guesses.
  • "Rewrite the file to be better." "Better" is undefined. The model optimizes for whatever it has seen most often, which is rarely your codebase's conventions.
  • "Make it faster / cleaner / more idiomatic." Same problem — no constraint, no measure, no acceptance test. Will produce diffs that look reasonable and break behavior.
  • "Generate the whole feature." A single prompt that asks for design, implementation, tests, and docs in one pass. The result cannot be reviewed safely; break it into S.C.A.F.F.-shaped steps.
  • "Just trust me." Any prompt whose instructions tell the model to bypass its own safety or verification behavior is a defect, not a productivity gain. Reject in review.
  • "Don't ask questions, just do it." Removes the model's ability to surface ambiguity. The ambiguity does not go away — it lands silently in the output.

If a teammate's prompt looks like one of these, use the C.L.E.A.R. interrogation prompt on the output and refuse to merge until intent and constraints are documented.

How to contribute prompts to this library

The library grows through team contributions. Until the public contribution channel opens, the path is:

  1. Fork the template into your team's internal wiki and use it for at least four real engagements.
  2. Capture the placeholders that every user filled in the same way — those become defaults rather than placeholders.
  3. Capture the placeholders that no user filled — those should be removed.

For the framework pages each template serves, see Frameworks overview.

Next

  • S.C.A.F.F. — the prompt-structure framework these templates implement.
  • V.E.R.I.F.Y. — the verification protocol the self-check templates ladder up to.
  • C.L.E.A.R. — the human review protocol the AI self-check templates do not replace.