Part V · Act on itChapter 17

Sixty-two habits that compound

The question What small, daily practices pay for themselves, and when does each one apply?

6 min read Action Step 17 of 20 3/4 in this part

In 30 seconds

  • Sixty-two habits, ordered by when they apply: setup, opening, retrieval, state, boundaries, delegation, hygiene.
  • Eight habits pay off in week one — five of them free.
  • The wins are mostly deletions and habits, not architecture.

You will be able to

  • Apply the first-week eight today
  • Open, run and end a session with deliberate context habits
  • Keep the gains with a quarterly routine

Each habit defers to its owning chapter: setup and prevention → chapter 3 and chapter 8; opening and retrieval → chapter 5; state and boundaries → chapter 6 and M-10; delegation → chapter 7; the quarterly loop → chapter 15.

The eight that pay for themselves in week one#

If you do nothing else from this chapter, do these. Three of the eight are free; the rest cost minutes.

# Habit Effort Payoff
6 Audit MCP servers with zero calls 10 min Candidate recovery when dead or duplicate surface dominates; verify and keep rollback
9 Four shell wrappers for your loudest commands An afternoon 60–90% less tool output P
1 Ignore files 5 min Prevents a whole class of failures
3 The inference test on the instruction file 20 min Smaller and more salient
20 A 200-token opener Per session Much less exploratory retrieval
43 Compact after a test passes, never mid-debug Free Avoids the worst compaction failures
45 Re-read the plan file right after compaction Free Protects the most error-prone step
51 Reset on the third repeated action Free Ends distraction loops at once

That is the shape of this whole field: the wins are mostly deletions and habits, not architecture.

Where the habits apply in a session's life

Habits are grouped by when they apply: setup once, opening a session, during the session for retrieval, state and boundaries, delegation, and ongoing hygiene. Setup1–18 · once Opening19–26 Retrieval27–34 State35–42 Boundaries43–54 Delegation55–60 ongoing hygiene, 61–62: re-audit quarterly; fix the repository when problems recur
Figure 1. The list below follows this order. Read the section for the moment you are in.

Before the session: setup, once#

  1. Write ignore files first. node_modules/, dist/, build/, *.lock, __generated__/, vendor/, .next/, snapshots, fixtures. The cheapest change in this research.
  2. Link CLAUDE.md to AGENTS.md. One file, read by 30+ tools P. Two copies guarantee divergence.
  3. Apply the inference test to every instruction line. Could a competent engineer infer it from the repository in two minutes? If yes, delete it.
  4. Put the three rules you most need obeyed at the end of the instruction file. The end of a block is more attended than its middle.
  5. Turn repeatedly violated rules into machinery. A rule broken in half your sessions is a wish. Make it a lint rule, a hook, a pre-commit check or a test.
  6. Audit MCP servers with zero calls in a representative sample. Delete only after verifying task coverage; keep a rollback.
  7. Prefer the shell to an MCP server for anything the shell already does: gh, psql, curl, rg, git.
  8. Check whether your harness already does it before installing anything. Deferred tools, usage reporting and compaction control are increasingly built in P.
  9. Write four shell wrappers for your four loudest commands. Quiet flag, filter, full output to a file, a digest plus the path.
  10. Make the pass/fail asymmetry explicit in your test wrapper. One line on pass; the full trace on fail.
  11. Never truncate the middle. Head and tail, roughly 30/70. Errors cluster at the end.
  12. Create a gitignored .agent/ scratch directory as the offload target.
  13. Give rg sane context: -C 8 at least. Fragment blindness is invisible and expensive.
  14. Install a symbol-level retrieval tool if your stack has language-server support.
  15. Get a live context-utilisation display. Awareness alone changes behaviour D.
  16. Measure your prefix tax once and write it down. Re-measure after every harness update.
  17. Put context configuration under version control: instruction files, ignore files, tool config, wrapper scripts.
  18. Write the transcript-grep script. Twenty lines of shell that count tool calls, rank commands by output volume and flag repeated calls.
transcript-stats.sh — three routing metrics from a JSONL transcript
#!/usr/bin/env bash
# Usage: transcript-stats.sh session.jsonl
# Adjust the jq paths to your harness's transcript format.
f="$1"
echo "== Tool calls by name =="
jq -r 'select(.type=="tool_use") | .name' "$f" | sort | uniq -c | sort -rn
echo "== Largest tool results (approx tokens = chars / 4) =="
jq -r 'select(.type=="tool_result") | "\((.content|tostring|length)/4|floor)\t\(.tool // "?")"' "$f" \
  | sort -rn | head -5
echo "== Repeated identical calls (possible loops) =="
jq -c 'select(.type=="tool_use") | {name, input}' "$f" | sort | uniq -c | awk '$1 >= 3' | sort -rn

Opening a session#

  1. One session, one coherent task. New task, new session. The most violated rule here.
  2. Spend 200 tokens on the opener. Goal, constraints, relevant paths, definition of done, and what not to do.
a 200-token opener
Goal: checkout requests time out under load (p95 > 5s since Tuesday).
Start with: src/checkout/service.ts and src/db/pool.ts.
Constraints: no new dependencies; do not touch legacy/ or change the public API.
Done when: `npm test -w checkout` passes and a load test at 200 rps keeps p95 < 800ms.
First: write PLAN.md with your hypotheses before editing anything.
  1. Name a file in the opener, even as a guess. It turns expensive exploration into cheap directed retrieval.
  2. State the definition of done: "Done when pytest tests/checkout passes with no new lint errors." Otherwise the agent invents a stopping condition.
  3. State what not to do: "Do not touch legacy/. Do not add dependencies. Do not reformat unrelated files."
  4. Do not paste the design document. Pointers, never prose.
  5. When resuming, open with the plan file, not a narrative. "Continue from PLAN.md" beats three paragraphs of recap.
  6. Ask for a plan before edits on anything over about 30 minutes. The plan becomes the plan file, which survives every boundary.

During the session: retrieval#

  1. Locate, then inspect, then read: grep -lgrep -n → read the symbol.
  2. Ask for symbols, not files: "read the handleRetry function", not "read client.ts".
  3. Expand along the reference graph. Found the function? Read its callers, not its neighbours.
  4. Search config explicitly when the code runs out: *.yaml, *.toml, .env*, CI files, feature flags.
  5. Cap search results and narrow first. A 3,000-hit grep is a distractor injection, not a search.
  6. Re-read before you re-edit. Your own edits invalidate your own context.
  7. Treat zero results as information. They redirect the hypothesis. That is grep's underrated advantage.
  8. Use git log -S and git blame for "when did this change?" Agents rarely reach for history unprompted.

During the session: output and state#

  1. Redirect; do not delete. Full output to a file, digest in context, path included.
  2. Make every stub self-describing. a3f9.log (14KB) — npm ci, exit 0, 2 peer-dep warnings, not a3f9.log (14KB).
  3. Offload after a delay, not immediately. Offloading the output you are about to read forces a recall.
  4. Update the plan file at state changes, not on a timer.
  5. Keep a "ruled out" section with reasons and evidence. It prevents re-proposing a rejected approach after a boundary.
  6. Add "last updated at turn N" to the plan file. Drift becomes visible.
  7. Cap the plan file at 80 lines. Longer means the task needed decomposing.
  8. Commit at every checkpoint. Git is offload with review attached, and the cheapest reversibility you own.

During the session: boundaries#

  1. Compact right after a test passes. Never mid-debug. Semantic triggering in its simplest form.
  2. Do not compact when stuck. Being stuck means you do not yet know what matters, so you cannot choose what to drop.
  3. Re-read the plan file as the first action after any compaction. It protects the step with the most errors (+0.108 on AppWorld S).
  4. Never compact twice. A second compaction summarises a summary. Reset instead.
  5. Keep exact strings verbatim in summaries: errors, versions, paths, line numbers, config keys, IDs.
  6. Put a done / in-progress / not-started block in every summary. It counters the 44.6% termination collapse on AppWorld S.
  7. Do not compact with fewer than five turns left. It is below breakeven C (chapter 10).
  8. Reset instead of arguing. Correcting a wrong fact appends a competitor and leaves the original.
  9. Reset on the third repeated action. Rephrasing will not help; distraction is a property of the context.
  10. Write the handoff note before you need it. Two minutes now saves twenty turns later.
  11. Put file:line pointers in handoffs, not descriptions.
  12. Put verification commands in handoffs, with their results: "pytest tests/checkout -q → 47 passed, at a3f9c1".

Delegation#

  1. Write the output schema before delegating. If it does not fit in 20 lines, the work is not isolatable.
  2. List the implicit decisions the sub-agent will face. If the list is not empty, fix them in the brief or do not delegate.
  3. Give sub-agents the minimum tool set.
  4. Add a notable_outside_scope field to every contract. The cheapest mitigation for contract loss.
  5. Save sub-agent transcripts and give the parent the path. It turns contract loss into offload.
  6. Never delegate debugging. The ruled-out hypotheses are the most valuable product, and they die with the sub-agent.

Ongoing hygiene#

  1. Re-audit quarterly, on the calendar. Thirty minutes. Without it you are back at baseline within two quarters P.
  2. When a context problem recurs, fix the repository. Three functions named parse_config is a repository problem wearing a retrieval problem's clothes.

Run the diagnostic to see which of these you need first; re-audit quarterly.

Key takeaways

  1. Spend 200 tokens on the opener: goal, paths, definition of done, what not to do.
  2. Locate, then inspect, then read.
  3. Compact after a test passes, never mid-debug; reset on the third repeated action.
  4. When a context problem recurs, fix the repository.

Terms used in this chapter

  • Fragment blindness — Reasoning about a code fragment without the control flow around it, such as a grep hit shown without the if statement that governs it.
  • Stub — What stays in context after an offload: an identifier plus just enough description to decide whether to fetch it.
  • Semantic triggering — Compacting on task events such as a sub-goal closing or a test passing, instead of at a token threshold or on a timer.
  • Contract loss — A sub-agent knew something relevant but did not report it because its output contract did not ask.