What you need to know
"Reuse" covers three different mechanisms that solve three different problems. Exam questions often hinge on telling them apart.
| Mechanism | Reuses | Solves |
|---|---|---|
| Prompt caching | Processing of an identical prompt prefix | Cost and latency of sending the same long prefix again and again |
| Modular prompt library | Prompt fragments and templates | Duplication and drift of instructions across a codebase |
| Skills | A complete, packaged procedure | Consistent, governed execution of a task across teams |
Prompt caching
When many requests start with the same content (system prompt, tool definitions, reference documents, stable examples), caching lets later requests read that prefix from cache instead of processing it again. Cached reads cost a fraction of normal input and arrive faster.
How to design for it:
- Static first, dynamic last. Put everything that never changes at the start and the per-request content (user message, customer data) after it. A cache breakpoint marks where the reusable prefix ends.
- Keep the prefix byte-for-byte identical. Any change before the breakpoint is a cache miss: a timestamp in the system prompt, reordered tool definitions, a changed example.
- Match the lifetime to the traffic. Cached content expires if unused for a short time (minutes by default, with a longer option at a higher write cost). Steady traffic keeps it warm; a few requests a day do not.
- Count the write cost. Writing to the cache costs more than normal input, so caching pays only when the prefix is long enough and read often enough.
When hit rates are lower than expected, cache diagnostics report why a request missed: usually something before the breakpoint changed.
Modular prompt libraries
A library of reusable prompt fragments (a code-review checklist, a tone guide, a citation rule) that engineers assemble into their own prompts. It is lightweight and flexible and suits a team or a codebase. Its weakness is drift: copies diverge, versions are hard to track, and different teams end up with different variants.
Skills
A Skill packages a whole procedure: instructions in a SKILL.md file, plus optional scripts and reference files. Claude sees a short description of each available Skill and loads the full contents only when a task needs it, so many Skills can be available without filling the context window. Skills can be versioned, reviewed and distributed, which makes them the choice when a procedure must run the same way everywhere.
| Need | Choose |
|---|---|
| A few shared phrases or checklists that teams adapt | Prompt library |
| A repeatable procedure that must be consistent across teams | Skill |
| Versioning, approval and rollback | Skill |
| The procedure needs scripts or reference files | Skill |
| Lower cost and latency for a repeated long prefix | Caching (works with either) |
In the exam
Reuse questions describe either a cost or latency problem with repeated content, or a consistency and governance problem with shared instructions. Pick caching for the first and a Skill (or a library, if flexibility matters more than governance) for the second. For caching scenarios, check the prompt order and anything that changes per request before the breakpoint.
Check your understanding
A cache hit rate is near zero even though every request uses the same 10,000-token system prompt. The prompt begins with "Current time: {now}". What is the cause?
Show answer
Answer: B. Any change before the cache breakpoint is a miss. Move the timestamp after the stable content, or drop it.
Twelve teams use drifting copies of a security-review procedure that includes a scanning script. Security wants one approved version. What fits best?
Show answer
Answer: A. A governed, distributable procedure with a bundled script is what Skills are for. Caching changes cost, not consistency, and pasted fragments are what drifted.
Which TWO situations make prompt caching worthwhile?
Show answer
Answer: B, C. Caching pays when a long identical prefix is read often while the cache is warm. Short, rare or constantly changing prompts pay the write cost without enough reads to recover it.
Apply it: Untangle reuse at Quillstone
Quillstone's teams each keep their own code-review prompt, and the security lead wants every review to apply the same secrets checklist. Meanwhile, the CI review bot sends a 9,000-token instruction block on each of about 300 pull requests per working day, its cache hit rate is 0%, and its system prompt starts with the pull request number.
- Decide the mechanism for each need: the secrets checklist, each team's style preferences, and a release-notes procedure that runs a version-check script.
- Fix the CI bot's caching and explain why the hit rate is zero.
- Estimate the monthly saving on the instruction block at Tier M, assuming 22 working days and that the cache stays warm through the working day.
Done when: you can say whether the saving alone justifies the work, or what else does.
Show model answer
1. Mechanisms
| Need | Mechanism | Why |
|---|---|---|
| Secrets checklist in every review | Skill, owned by security, versioned | Must be identical everywhere and approved |
| Team style preferences | Team prompt fragments or each repository's project instructions | Teams need to adapt them; governance is light |
| Release notes with a version-check script | Skill | A procedure with a bundled script, used across teams |
2. Caching. The pull request number at the top changes on every request, so the prefix is never identical and every call misses. Move it, and all other per-request data, after the stable instructions and set the breakpoint at the end of the instruction block.
3. Saving. 300 × 22 = 6,600 reviews a month. Uncached: 6,600 × 9,000 = 59.4 million tokens × $3 per million = about $178. Cached reads at 10%: about $18, plus a few cache writes a day. Saving: about $160 a month. On its own that does not justify much engineering time; the stronger reasons are lower latency on every review and the fact that the fix is a few lines. The Skill, not caching, solves the consistency problem.