Working-Memory Prompts

Operational prompts for the scaffolding loop (Chapter 6). Each template is verified against Claude 3.5 Sonnet, Claude Code, and the OpenAI o-series as of 2026-06. Templates are copy-paste-ready; replace bracketed placeholders before use.

NOTES.md template

The externalized-scratchpad pattern from commitment 3. Drop this skeleton into a NOTES.md file at the start of any multi-iteration task; the agent reads and writes to it between iterations.

# [Task name] ## Goal [One sentence: what "done" looks like, measured concretely.] ## Plan 1. [ ] [First sub-task] 2. [ ] [Second sub-task] 3. [ ] [...] ## Verifiable stop [The check that closes each iteration. E.g. "npm test passes" or "all 12 sections of the doc have a verified citation."] ## Tried and abandoned (Capture dead-ends here so the loop does not revisit them. Include WHY the path was abandoned, not just that it was.) ## Open questions for the user (Surface ambiguities here rather than guess. The user reads this section first when they check on the work.) ## Handoff state [Updated at the end of each session if the task spans more than one session. The next session reads this first.]

Why this shape: the four fixed sections map to four of the seven commitments (verifiable stop, debt accumulation, frame before solve via "open questions," externalized memory via the whole file). The "Handoff state" section makes the file survive session boundaries cleanly.

Scaffolding-loop contract

The system prompt or initial-instruction that establishes the loop discipline before the work starts. Use at the start of any task expected to run for more than one iteration.

You are working on [task description]. Discipline: 1. Read NOTES.md before each action. Update it after each action. 2. No iteration is complete until [verifiable stop condition]. 3. If you try an approach and it fails, capture WHY in the "Tried and abandoned" section before trying anything else. 4. If you discover an ambiguity in the original request, surface it in "Open questions for the user" rather than guessing. 5. At natural breakpoints, refresh the "Handoff state" section so the next session can resume cleanly. You do not need to ask permission to read files, run tests, or update NOTES.md. You do need to surface (a) ambiguities in the request, (b) approaches you abandoned and why, and (c) any action with side-effects beyond NOTES.md and the test runner.

Trade-off: this is a verbose instruction. For short tasks it is over-rigging (see materiality prompts). For tasks expected to span 30+ minutes or a context-cliff event, it pays for itself the first time the loop survives a compaction without losing state.

Verifiable-stop checklist

A pre-iteration check that the loop has a real stop condition. Use at the start of any task; if the answer to any of these is unclear, push back on the request before starting.

Before I start iterating, confirm: 1. What is the stop condition? (Be specific. "Looks right" is not a stop condition; "test X passes" is.) 2. How will I know I have hit the stop condition? (A test pass? A specific output value? A user sign-off?) 3. What is the per-iteration cost? (Time, tokens, side-effects.) If a single iteration is expensive, fewer-and-larger iterations may beat many-and-cheap. 4. What is the failure budget? (How many iterations can fail before I escalate vs. push through? Materiality-dependent.) If 1 or 2 are unclear, stop and clarify with the user before running the loop.

Why this is at the start: the most common loopmaxxing failure is iterating without a real stop. The loop runs forever (or until a budget cap), produces nothing measurably better, and the user retroactively realizes the task was never well-defined. Five questions up front prevents the entire failure class.

Compaction-survivor prompt

If working in a harness that emits a context-compaction event, use this template as the first instruction after the compaction so the agent re-reads state from NOTES.md rather than confabulating from the summary.

A context compaction just occurred. Before any other action: 1. Read NOTES.md in full. 2. Locate the "Handoff state" section. That is your current state. 3. Confirm the "Plan" section - which sub-tasks are [x] done vs. [ ] pending. 4. Check "Tried and abandoned" so you do not re-try a path the loop already discarded. 5. Resume from the first [ ] pending sub-task. Do not assume state from the compaction summary. NOTES.md is the source of truth.

Trigger: automatic in harnesses that expose compaction events; manual otherwise (the user pastes this prompt when they notice context degradation).

Practitioner notes

Keep NOTES.md in the working directory the agent reads from. Do not put it somewhere the agent has to be told about - the agent should find it by convention.
NOTES.md is plain markdown, not structured data. The agent benefits from human-readable structure; the user benefits from being able to read the file directly to see what is happening.
Version-control NOTES.md for long-running tasks. The diff history becomes a free audit trail.
For ad-hoc / one-off tasks, the contract is over-rigging. Use the simpler prompts library entry point for materiality calibration on whether to bring the full discipline.