Usage Guide
A path for those still setting up their workflow — where to start, what triggers adding more, and how to combine patterns. If a symptom has already shown up, starting from Find by Symptom is faster.
This catalogue has 17 patterns, but adopting all 17 from day one isn't the intent. Many of the patterns — resident instructions, delegation boundaries, approval gates — carry a cost just from being adopted. Resident material rides along on every turn; boundaries cost something on every round trip. So the path runs in one direction: start minimal, and when a symptom is actually observed, add only what addresses that symptom.
The Adoption Ladder
Before picking a pattern, check which rung your current usage sits on. The higher the rung, the more there is to manage, and the more ways it can break.
| Rung | Shape of usage | What gets added to manage | Entry-point patterns |
|---|---|---|---|
| 0 | Used only within a single conversation | The conversation itself | Session Boundary Design / Matching Thinking Depth to the Task / Diff Review and Incremental Adoption |
| 1 | Places a resident instruction file | Resident context | Instruction Layering and Scoping / Rules Ranked by Binding Force / One Authoritative Source for Instructions / Resident Context Inventory |
| 2 | Delegates investigation and work, and parallelizes it | Boundaries, and their cost | Read-and-Discard Isolation / The Break-Even Point of Delegation |
| 3 | Puts work on paths a human doesn't watch | Permissions and gates | Strong Gates for Unattended Paths / Bounding Permissions by Structure / Separating Mechanical Gates from Semantic Gates |
This ladder is an order for adding, not discarding. Moving up a rung doesn't retire the patterns from the rungs below — they keep working. In fact, moving into delegation or unattended operation without first settling rungs 0-1 — what stays resident, where the conversation gets cut — just replicates the same clutter into the delegated work and the unattended path. Move up a rung only once a symptom has actually shown up at the current one.
Checks Before Handing Off Work
Decide which patterns to combine for one piece of work you're about to hand off. This isn't a branch — it's a checklist. Combine every pattern whose row comes back "yes."
The same checklist, available as a linked table.
| Question | Combine if "yes" |
|---|---|
| Would rework be large if the direction turns out wrong | Preemptive Plan Review |
| Does the volume read far exceed the volume brought back | Read-and-Discard Isolation. See the price tag in The Break-Even Point of Delegation |
| Won't the work fit in a single conversation | Session Boundary Design |
| Does it hand over permission for an irreversible operation | Bounding Permissions by Structure |
| Does it run on a path a human isn't watching | Strong Gates for Unattended Paths |
| (For every task) what counts as passing | Making the Verification Target Explicit / Separating Mechanical Gates from Semantic Gates |
| (For every task) how the deliverable gets received | Diff Review and Incremental Adoption |
Five Rules of Thumb
Rules of thumb for narrowing down patterns based on your environment and the nature of the work. The evidence behind each one lives on the pattern's own page, with its label attached.
Rule 1: Structure Over Instructions
An instruction like "be careful" gets buried in context and forgotten; structure doesn't. To stop a dangerous operation, don't pile on more warnings — Bounding Permissions by Structure. On a path a human isn't watching, put Strong Gates for Unattended Paths in place, more so than ever.
Rule 2: Don't Let the Model Judge What a Machine Can Judge
Don't leave correctness that lint, tests, or type checks can already determine to the model's eyeball check (Separating Mechanical Gates from Semantic Gates). The same goes for reproducible computation — Computation as Code. On top of that, don't leave what counts as passing to the model's guesswork; hand it over as a contract (Making the Verification Target Explicit).
Rule 3: Resident Material Is Rent
Anything that keeps riding along on every turn pays its cost over the entire operating period, not just the moment it's added. Before adding, count it against the criteria in Resident Context Inventory, and if you do add it, scope it narrowly (Instruction Layering and Scoping). Ordering matters too — put what doesn't change up front and reuse kicks in (Keeping the Prefix Stable).
Rule 4: Delegation Comes With a Price Tag
Isolation and delegation protect the main context, but they aren't free (The Break-Even Point of Delegation). Whether to isolate is judged not by the size of the task but by the ratio between what's read and what's brought back (Read-and-Discard Isolation).
Rule 5: A Human Steps In Where the Fix Is Cheapest
A plan before execution is the cheapest deliverable to fix (Preemptive Plan Review), and a finished deliverable shouldn't come down to an all-or-nothing choice between accepting and discarding it (Diff Review and Incremental Adoption). Failures that happen anyway get recorded concretely, not as abstract admonitions, to stop them recurring (Failure as Institutional Memory).
Add Only Once a Symptom Is Observed
A procedure for adding complexity later.
- Start minimal — Keep resident instructions thin, and hand over one-off instructions on the spot. Run work at rungs 0-1.
- Add once observed — Once a failure or inconvenience actually happens, find the matching pattern with Find by Symptom, and add only what addresses that symptom.
Adding rules or resident material ahead of time for "might need it someday" is rent paid in advance. What gets added swells the resident context itself and buries the constraints that matter. Once something is added, put it on the Resident Context Inventory's list, and retire what isn't earning its keep.
Patterns Are Combined in Practice
Real-world operation is never completed by a single pattern. Typical combinations:
- Investigating a large codebase = Read-and-Discard Isolation + The Break-Even Point of Delegation + Session Boundary Design
- A long-running implementation = Preemptive Plan Review + Making the Verification Target Explicit + Session Boundary Design + Diff Review and Incremental Adoption
- A team maintaining instruction files = Instruction Layering and Scoping + Rules Ranked by Binding Force + One Authoritative Source for Instructions + Failure as Institutional Memory + Resident Context Inventory
- Putting work on unattended automated runs = Strong Gates for Unattended Paths + Bounding Permissions by Structure + Separating Mechanical Gates from Semantic Gates + Diff Review and Incremental Adoption
The Related section at the end of each pattern page describes the boundary with neighboring patterns and where combinations start.