Reusable prompts for a known tech stack

The prompts worth saving

Part three of three. Most prompts are disposable — describe the task, get the change, move on. The ones worth turning into repo artefacts are the ones with a procedure attached: the sequence of steps that has to happen in order, the checks that have to run, the places where the work usually goes wrong.

A good test is whether you have corrected the same omission twice. If an agent has now twice added a page without its registry entry, or twice skipped the verification step, that is not a prompting failure — it is a missing command.

A command that encodes the whole procedure

Claude Code reads markdown files from .claude/commands/ as slash commands, with $ARGUMENTS carrying whatever followed the command name. That makes a command the natural home for a multi-step procedure that must not be improvised.

---
description: Scaffold a knowledge base post end to end
---

Create a new knowledge base post for: $ARGUMENTS

Follow content/POST_TEMPLATE.md exactly — do not restate its rules from
memory, read it. Then:

1. Add the registry entry to `data/posts.ts` FIRST. The build fails without
   it, and the failure is confusing if the page already exists.
   - `title` <= 60 chars, phrased like the target query
   - `description` <= 165 chars, answer-first
   - `targetQuery` is the query this post is written to win
   - `image` is required: 1600x900 at public/knowledge-base/<slug>.jpg
2. Create `app/knowledge-base/<slug>/page.tsx` using the post kit
   (AnswerBox, PostSection, ComparisonTable, DecisionRecord, PostFAQ).
3. The AnswerBox MUST be the first child — PostLayout splits on it to place
   the illustration, and it is what passage-level extractors read.
4. Every H2 is a sub-question answered in its own first sentence.
5. Include at least one experience artifact: a real number, a shipped
   snippet, or a DecisionRecord. No invented statistics — if there is no
   real number, use a qualitative claim.
6. Run `npm run verify`. Fix what it reports; do not adjust the thresholds.

Stop and ask if the topic has no real artifact behind it. A post with
nothing experienced in it is worse than no post.

Note what the command does not do: it never restates the performance budget, the voice rules, or the full template checklist. It points at the files that own those. When the template changes, the command is still correct — which is the property that decides whether an artefact like this survives six months.

Stack prompts are mostly a list of what not to reach for

A stack-specific prompt earns its keep by closing off the defaults. Models have strong priors from the most common tutorial version of any stack, and those priors are usually wrong for a specific codebase — a client component where a server one would do, a date library for one format call, an icon package for one chevron.

---
description: Add a component to the Next.js App Router site
---

Build a component for: $ARGUMENTS

Stack facts (do not infer these from other projects):
- Next.js App Router. **Server component by default.** Add "use client"
  only for real interactivity — an event handler alone is not enough.
- Tailwind with brand tokens from tailwind.config.ts. Never a raw hex.
  Contrast pairings are solved; `tk-slate` text on light backgrounds sits
  at /70 minimum.
- Motion: CSS only. `components/motion/Reveal` for scroll-in. Animation
  libraries never enter the layout path.
- Images: next/image with explicit dimensions. Fixed aspect box so CLS
  stays 0. `priority` only above the fold.
- No new runtime dependencies. If one seems necessary, stop and say why.

Before writing, read two existing components in the same directory and
match their conventions. After writing, run `npm run verify`.

“Read two existing components and match them” does more work than the rest of the file combined. It converts a rule you would otherwise have to enumerate — naming, file layout, comment density, prop shapes — into an instruction to go and look, which generalises to conventions you never wrote down.

Push the reading somewhere else

The last piece is knowing what not to do in the main session. Anything read-heavy where you only want the conclusion — auditing every article for a pattern, checking whether a claim holds across a directory, verifying an API shape against documentation — is work for a subagent. It spends its own context window on the reading and returns the finding.

That matters more than it sounds. The main session's context is the thing holding your intent, the constraints, and the half-finished change; filling it with the contents of forty files is how an agent starts forgetting the rules it was following twenty minutes ago. While writing this series, the Claude Code configuration details were verified by a separate agent against the official documentation, and it came back with specifics and a list of things it was not confident about — which is exactly the shape of answer you want before publishing config examples.

The series, in one line each

Part one moves facts into typed structures so the build enforces them. Part two gives the agent an isolated environment and a browser so it can check its own work. This part turns both into commands that make the good path the easy one. None of it makes an agent smarter — it makes the correct behaviour cheaper than the incorrect one, which is the only lever that holds up over months.

Reusable prompts are worth the effort once the stack is settled — which is itself a decision worth making deliberately, and one I make with clients on AI integration work.

Questions