---
framework: Agentic Engineering Maturity — Factory Edition
version: 2026.06.0
kind: companion-guide
lens: personal
title: Personal Checklist — Companion Guide
---

# Personal Checklist — Companion Guide

**Version `2026.06.0`**

Every item in the checklist, explained — in the same order and wording. Each entry gives the *why*, *what good looks like*, *how to check*, and the failure modes.

**How to read each entry**

- **Stage · Tags · Concept** — the maturity stage, theme tags, and the 2026 idea it draws on.
- **Why now** — what changed in the agentic era that makes this matter.
- **What good looks like** — the observable signal that you actually do this.
- **How to check** — a quick, honest self-test.
- **Failure modes** — how the checkbox goes green while the practice stays hollow.

---

## 1. Intent & Specification

### Before non-trivial work I write the intent down — goals, constraints, and an explicit definition of done — not just the task
`S2` · `intent` `spec` · **Concept:** Spec-Driven Development / Intent Debt

**Why now.** When work fans out to an agent (or many), the spec is the leverage point — ambiguity multiplies across every run. The intent is also the one input a model can't generate for you.
**What good looks like.** A short written intent precedes implementation: what, why, the constraints, and how you'll know it's done.
**How to check.** Look at your last three non-trivial tasks — was there a written intent before the first generation prompt?
**Failure modes.** "Build me X" one-liners; a definition of done that only exists in your head and shifts as you go.

### I specify outcomes and let the agent propose the implementation — I keep the *what/why* separate from the *how*
`S2` · `spec` · **Concept:** Factory Model

**Why now.** Over-specifying the *how* wastes the model's strength and hides your real requirements; under-specifying the *what* lets it invent requirements you never agreed to.
**What good looks like.** Your prompts state the outcome and constraints; you let the agent draft an approach and you judge it.
**How to check.** Can you point to a recent task where you reviewed the agent's *plan* before its code?
**Failure modes.** Dictating implementation detail you haven't thought through; or handing over a vague goal and accepting whatever comes back.

### When the agent surfaces an unknown, I update the spec, not only the code
`S2` · `spec` `intent` · **Concept:** Intent Debt

**Why now.** Agents expose gaps in your thinking fast. If the resolution lives only in the diff, the rationale evaporates the moment the session ends.
**What good looks like.** Discovered constraints and decisions flow back into the spec or a decision note, not just the implementation.
**How to check.** After a task that hit a surprise, is the surprise recorded anywhere a future reader would find it?
**Failure modes.** Answering the agent's clarifying question in chat and letting that answer disappear.

### For load-bearing decisions I record the *why* (a short decision note / ADR) the moment I make it
`S3` · `intent` `decision-log` · **Concept:** Intent Debt

**Why now.** Recording *why* at decision time is nearly free; reconstructing it eight months later, after you've moved on, costs a fortune — and an agent will fabricate a confident wrong reason.
**What good looks like.** Consequential choices (a queue vs. a direct call, a non-obvious default) leave a one-paragraph trail.
**How to check.** Pick a recent architectural choice — can you find the recorded reason without relying on memory?
**Failure modes.** "An agent suggested it and it seemed fine" as the only surviving rationale.

### My specs are written so an agent can act on them *and* a reviewer can evaluate against them
`S2` · `spec` `review` · **Concept:** Spec-Driven Development

**Why now.** A spec that can't be checked against can't anchor a review — and review is where the bottleneck now sits.
**What good looks like.** Acceptance criteria a second person (or a checker agent) could verify without asking you.
**How to check.** Hand your spec to a colleague — could they tell whether the result meets it?
**Failure modes.** Aspirations ("make it clean") with nothing measurable to test against.

### I refuse to start from a vague spec — I sharpen "make it work" into measurable outcomes before any code is generated
`S2` · `spec` `quality` · **Concept:** Factory Model

**Why now.** Vague specs produce vague results, and at fleet scale each agent goes wrong in its own direction.
**What good looks like.** You push back on (your own) fuzzy asks and rewrite them before generation.
**How to check.** Does your prompt history show sharpening steps before implementation on bigger tasks?
**Failure modes.** Letting deadline pressure turn "I'll just see what it produces" into the plan.

### My definition of done names the non-negotiables for this change (performance, accessibility, security), not just "it functions"
`S3` · `spec` `quality` · **Concept:** Spec-Driven Development

**Why now.** "Functionally correct" is the lowest bar; agents hit it and stop. The qualities you don't name are the ones that silently regress.
**What good looks like.** Done includes the explicit bar that matters here — latency budget, a11y, security posture, etc.
**How to check.** Read your last definition of done — does it mention anything beyond "it works"?
**Failure modes.** Shipping something that passes tests but misses the quality that actually mattered.

---

## 2. Context, Memory & Harness

### I attach the specific files, types, and examples a task needs and strip the noise — not a whole-codebase dump
`S2` · `context` · **Concept:** Harness Engineering (context)

**Why now.** Loading everything degrades the model before it acts; the right slice of context is what prevents hallucination.
**What good looks like.** Prompts reference concrete paths/examples and deliberately omit the irrelevant.
**How to check.** Open your last agent thread — was the attached context proportional to the task?
**Failure modes.** `@codebase` for a two-line change; no example for a new pattern.

### I notice when the agent starts guessing and add context instead of telling it to push on
`S2` · `context` `quality` · **Concept:** Harness Engineering

**Why now.** A guessing agent produces confident wrongness; more context is cheaper than the cleanup.
**What good looks like.** You stop and supply the missing fact rather than saying "continue."
**How to check.** Recall a recent run where the agent went sideways — did you re-context or just push it forward?
**Failure modes.** Treating "keep going" as a fix for missing information.

### I keep durable memory outside the chat (a task/progress file, notes in `AGENTS.md`) so work survives a context reset
`S3` · `harness` `memory` · **Concept:** Self-Improving Loops

**Why now.** The model forgets everything between runs; memory has to live on disk, not in the conversation.
**What good looks like.** A state/progress file or notes the next session can read to pick up where you stopped.
**How to check.** Could you resume a multi-session task tomorrow from files alone?
**Failure modes.** All the context trapped in one long chat that's about to be compacted away.

### I treat `AGENTS.md` / rules as an intent ledger — conventions and "we don't do X because…", not autogenerated boilerplate
`S3` · `harness` `intent` · **Concept:** Intent Debt

**Why now.** Autogenerated files describe what the code *is*; agents most need what the team *means* and can't infer.
**What good looks like.** Your rules encode conventions and hard-won "don't do this because" notes.
**How to check.** Does your `AGENTS.md` contain anything an `/init` couldn't have produced?
**Failure modes.** A generated file nobody curates; rules with no rationale.

### On long tasks I manage context rot deliberately — compact, hand off to a fresh session with a brief, or offload long outputs to files
`S3` · `harness` `context-rot` · **Concept:** Harness Engineering

**Why now.** Models degrade as the window fills; long jobs need active context hygiene, not just a bigger window.
**What good looks like.** You compact, reset with a structured hand-off, and push 2,000-line logs to files instead of into context.
**How to check.** On your last long task, did quality hold across context boundaries?
**Failure modes.** Letting the window fill until reasoning quietly degrades.

### When the model underperforms I tune my own harness (prompts, tools, ignore files) instead of only waiting for a better model
`S3` · `harness` · **Concept:** Harness Engineering ("skill issue")

**Why now.** A decent model with a great harness beats a great model with a bad one — most failures are configuration, not weights.
**What good looks like.** A bad run prompts a harness change you can name.
**How to check.** When did you last fix an agent failure by changing your setup rather than your model?
**Failure modes.** Filing every failure under "wait for the next version."

### I keep the agent's tool/skill menu small and relevant to the task at hand
`S2` · `harness` `tooling` · **Concept:** Harness Engineering

**Why now.** Every tool's description is stamped into the prompt; ten focused tools beat fifty overlapping ones.
**What good looks like.** You enable what the task needs and leave the rest off.
**How to check.** Count the tools/MCPs live in your last session — could the model hold that menu in its head?
**Failure modes.** Every MCP installed and enabled "just in case."

---

## 3. Loops, Autonomy & Orchestration

### I match autonomy to risk per task (suggest / apply-with-confirm / apply / merge) rather than defaulting to max autonomy
`S2` · `autonomy` · **Concept:** Agentic Code Review (blast radius)

**Why now.** The right autonomy depends on what happens when it breaks; one setting for everything is wrong somewhere.
**What good looks like.** You can name the autonomy level you chose for your last few tasks and why.
**How to check.** Did your riskiest recent change run at lower autonomy than your safest?
**Failure modes.** Max-autonomy agent on a prod-DB task; suggest-only for a typo.

### For repeatable work I build a small loop (automation + checker + state file) instead of re-prompting by hand each time
`S4` · `loop` · **Concept:** Loop Engineering

**Why now.** The leverage moved from prompting to designing the system that prompts — recurring work shouldn't route through your keystrokes.
**What good looks like.** At least one recurring task runs as a loop you designed once.
**How to check.** What have you automated into a loop in the last month?
**Failure modes.** Pasting the same wall of instructions into a fresh chat every time.

### I split the maker from the checker — a different agent or a fresh pass verifies work, never the one that produced it
`S3` · `loop` `verification` · **Concept:** Harness Engineering (planner/generator/evaluator)

**Why now.** Agents skew positive grading their own work; a separate checker makes "it's done" mean something.
**What good looks like.** Verification runs as a distinct step/agent with different instructions.
**How to check.** On your last non-trivial task, who checked the work — the maker or someone else?
**Failure modes.** Asking the author agent "is this correct?" and believing it.

### I run parallel agents in isolated worktrees so they don't collide — and only as many as I can actually review
`S3` · `loop` `orchestration-tax` · **Concept:** Loop Engineering / Orchestration Tax

**Why now.** Worktrees remove the mechanical collision, but your review bandwidth is the real ceiling.
**What good looks like.** Parallel runs are isolated, and the count is bounded by what you can review well.
**How to check.** Did your last parallel session produce more diffs than you could read properly? 
**Failure modes.** Spawning 20 because the UI lets you; agents stepping on each other's files.

### I scale my fleet to my review rate, batch my reviews, and protect uninterrupted time for judgment-heavy work
`S3` · `orchestration-tax` · **Concept:** The Orchestration Tax

**Why now.** Your judgment is the single-threaded resource; throughput is capped by it, not by how many agents you start.
**What good looks like.** Backpressure (fewer agents), batched reviews, and protected deep-work time.
**How to check.** Do you feel "busy with 20 agents" but shipping little? That's the tax unpaid.
**Failure modes.** Context-switching between agents all day; reviewing the fifth PR with a tired glance.

### I sort tasks into "safe to delegate to a background agent" vs. "the judgment is the work" — and don't parallelize the second pile
`S3` · `orchestration-tax` `autonomy` · **Concept:** The Orchestration Tax

**Why now.** Parallelizing judgment-heavy work just thrashes the lock and degrades everything.
**What good looks like.** Two explicit piles; background agents for the isolated work, full attention for the hard calls.
**How to check.** Was your last "weird bug" or architecture task run solo, with the lock held?
**Failure modes.** Trying to multitask three complex design problems across agents at once.

### I give long-running agents explicit stop conditions and a verifiable "done," not an open-ended goal
`S3` · `loop` `autonomy` · **Concept:** Self-Improving Loops

**Why now.** An unattended loop with no verifiable stop is a loop making mistakes unattended.
**What good looks like.** A concrete completion test ("all tests in X pass and lint is clean") and a max-iteration / time cap.
**How to check.** Did your last autonomous run have a checkable stop condition?
**Failure modes.** "Keep improving it" with no exit; runaway token spend.

---

## 4. Verification & Review

### I tier my scrutiny by blast radius — a glance for low-risk diffs, the full stack for auth / billing / data paths
`S2` · `review` `blast-radius` · **Concept:** Agentic Code Review

**Why now.** Reviewing everything to the same depth wastes scarce attention; match effort to the cost of being wrong.
**What good looks like.** Config tweaks get a linter and a glance; payment paths get types, tests, two reviewers, and you.
**How to check.** Did your last high-risk change get more scrutiny than your last trivial one?
**Failure modes.** Heavy review on boilerplate; waving through an auth change because CI was green.

### I read AI-generated diffs as if a junior wrote them; "the tests pass" is never the whole review
`S2` · `review` `comprehension` · **Concept:** Cognitive Surrender

**Why now.** Surface correctness (compiles, lints, looks like the file) is exactly the wrong filter for systemic correctness.
**What good looks like.** You apply the same standard you'd apply to a human junior's PR.
**How to check.** On your last merge, could you have caught a subtle transaction-ordering bug — or did you scan and approve?
**Failure modes.** Ratifying a 600-line PR because the variable names looked reasonable.

### I read the *test* changes more carefully than the code, watching for assertions rewritten to match broken behavior
`S3` · `review` `testing` · **Concept:** Agentic Code Review

**Why now.** A classic agent move is to "fix" a failing test by editing the assertion to match new, broken behavior — green check, wrong code.
**What good looks like.** Any diff that rewrites many tests gets the tests read first.
**How to check.** When tests changed in your last PR, did you confirm each edit was *correct*, not just green?
**Failure modes.** Trusting "200 tests updated, all passing."

### I run at least one AI reviewer on my work, and a second *different* one on high-risk changes — treating both as sensors, not verdicts
`S3` · `review` `heterogeneous` · **Concept:** Agentic Code Review (heterogeneity)

**Why now.** Reviewers built differently overlap surprisingly little — four tools agreed on almost no findings; two *different* ones beat two copies of the best.
**What good looks like.** One reviewer on everything; a second, different one on the risky paths.
**How to check.** What reviewer(s) ran on your last high-stakes PR, and how different are they?
**Failure modes.** Two instances of the same model agreeing confidently in the same blind spots.

### I never merge just to clear a queue — when I click merge, I own it
`S2` · `review` `accountability` · **Concept:** Human-on-the-loop

**Why now.** A model can't be paged at 3am; whoever merges is accountable for what shipped.
**What good looks like.** You merge because you're confident, not because the queue is long.
**How to check.** Was your last merge a decision, or a queue-clearing reflex?
**Failure modes.** Lazy-merging whatever the bot approved.

### Before opening a PR I attach the intent, a readable (small) diff, and proof the tests ran, so I'm not the first human to understand it
`S3` · `review` `intake` · **Concept:** Agentic Code Review (intake bar)

**Why now.** Pushing intent-reconstruction onto the reviewer is where the 441%-longer review times come from; supply it up front instead.
**What good looks like.** Your PRs open with purpose, a small diff, and evidence of a real test run.
**How to check.** Could a reviewer understand your last PR without reverse-engineering it?
**Failure modes.** A 3,500-line diff with no description and no test output.

### I keep my PRs small on purpose, instructing agents to produce reviewable commits
`S2` · `review` `quality` · **Concept:** Agentic Code Review

**Why now.** Agent PRs run large, and a large unreviewable PR is either rejected or rubber-stamped. The unit of review is the unit of comprehension.
**What good looks like.** You instruct for small commits; big changes are split.
**How to check.** What's the size distribution of your recent AI PRs?
**Failure modes.** One mega-diff per feature because the agent could produce it in one go.

---

## 5. Tests & Deterministic Gates

### I add or update real tests in the same change as the code — never "tests later"
`S2` · `testing` · **Concept:** Factory Model (tests matter more)

**Why now.** With a fleet optimizing for "tests pass," tests written after the fact tend to encode whatever the code happens to do.
**What good looks like.** Tests ship in the same PR as the production code they cover.
**How to check.** Do your last five AI PRs include test changes in the same merge?
**Failure modes.** "We'll add tests in a follow-up"; snapshot tests that always pass.

### For non-trivial logic I write (or confirm) the tests before the implementation and check they fail first
`S3` · `testing` `tdd` · **Concept:** Red/Green TDD

**Why now.** Red/green is the mechanism that proves the implementation does what you meant, not what it happened to do. "Use red/green TDD" is one of the highest-leverage instructions you can give an agent.
**What good looks like.** Tests exist and are seen to fail before the implementation makes them pass.
**How to check.** Can you show a red-before-green sequence on a recent non-trivial change?
**Failure modes.** Tests written to fit the code after it's already "done."

### I check that generated tests assert behavior that would actually fail if the code were wrong — not just walk the happy path
`S2` · `testing` `review` · **Concept:** Verification Bottleneck

**Why now.** A green suite full of weak assertions is worse than none — it manufactures false confidence.
**What good looks like.** You check that assertions would actually fail if the behavior were wrong.
**How to check.** Pick a recent AI-written test — would it catch a real regression?
**Failure modes.** Tests asserting that code ran, not that it's correct.

### I lean on deterministic gates (types, lint, tests) to carry load human reading can't, and I keep them green *honestly*
`S2` · `testing` `gates` · **Concept:** Agentic Code Review (CI as the wall)

**Why now.** Deterministic gates are the one part of the pipeline that can't be talked out of their verdict by a confident paragraph.
**What good looks like.** Gates are strict, and you fix the code rather than weaken the gate.
**How to check.** Have you ever loosened a check just to get an agent's change to pass?
**Failure modes.** Skipping lint, lowering thresholds, or deleting a failing test to go green.

### I use mutation testing or targeted checks where "coverage is green" isn't enough to trust the suite
`S4` · `testing` `quality` · **Concept:** Agentic Code Review

**Why now.** Coverage says a line ran; mutation testing says the test would notice if that line were wrong.
**What good looks like.** Critical paths have stronger-than-coverage guarantees.
**How to check.** On your most important module, do you know whether the tests would catch a planted bug?
**Failure modes.** Treating a coverage percentage as proof of safety.

### I let the machine prove the boring 80% (a passing test, a screenshot, a trace) so I spend attention on the 20% that needs judgment
`S3` · `testing` `orchestration-tax` · **Concept:** The Orchestration Tax

**Why now.** Your attention is the scarce resource; don't spend it on what a machine can verify itself.
**What good looks like.** Tasks terminate in machine-checkable evidence, freeing you for the judgment calls.
**How to check.** Does your workflow make agents produce proof, or do you eyeball everything?
**Failure modes.** Manually verifying things a test or screenshot could have proven.

---

## 6. Safety, Security & Guardrails

### Real credentials, customer data, and production keys stay out of every prompt — I work with synthetic stand-ins instead
`S1` · `security` · **Concept:** Harness Engineering (safety)

**Why now.** Secrets in prompts can leak via logs, history, or shared threads.
**What good looks like.** Synthetic fixtures and placeholders; no real keys or prod strings in any chat.
**How to check.** Search your recent chats for `sk-`, `AKIA`, `password=`, connection strings.
**Failure modes.** Pasting `.env` "for convenience"; screenshotting a prod dashboard.

### I scope tool permissions per project (file, terminal, network, MCP) and don't run "allow all" against prod-adjacent work
`S2` · `security` `permissions` · **Concept:** Harness Engineering

**Why now.** Default-allow on prod-adjacent work turns one bad agent step into an incident.
**What good looks like.** Default-deny, widened only for the task, narrowed again after.
**How to check.** Open your agent's permission settings for your current project — is anything on "allow all"?
**Failure modes.** Weekend-wide terminal access left enabled; prod creds in a dev profile.

### I run agent-executed code in a sandbox / ephemeral environment, especially when untrusted input is involved
`S3` · `security` `sandbox` · **Concept:** Harness Engineering (sandboxes)

**Why now.** Running agent-generated code on your laptop is risky and doesn't scale to many parallel agents.
**What good looks like.** Execution happens in an isolated env you can tear down.
**How to check.** Where did your last agent-run code actually execute?
**Failure modes.** `curl | bash` straight onto your machine because the agent suggested it.

### I assume any outside text the agent ingests (web, issue threads, docs, tool results) may carry hostile instructions, and keep irreversible actions behind a human
`S3` · `security` `injection` · **Concept:** Agentic Code Review (prompt injection)

**Why now.** Agent features that pipe user-controlled text into a model are a fresh injection surface; the vulnerability is latent in the data, not visible in the diff.
**What good looks like.** Untrusted text is summarized/checked and never directly triggers destructive actions.
**How to check.** Could a malicious issue comment make your agent run something dangerous?
**Failure modes.** Letting an agent act on raw web/issue content unfiltered.

### I vet MCP servers and tools before installing — source, permissions, supply-chain risk — because their descriptions are trusted text the model reads
`S3` · `security` `mcp` · **Concept:** Harness Engineering

**Why now.** A tool's description populates the prompt; a sloppy or malicious MCP can prompt-inject your agent before you type anything.
**What good looks like.** You check source, signature, and scope before adding a server.
**How to check.** Can you account for every MCP server your agent can reach?
**Failure modes.** Installing servers on vibes; unpinned versions.

### I keep destructive operations behind a confirmation or block (force-push, prod migration, mass delete), not just an instruction
`S3` · `security` `guardrails` · **Concept:** Harness Engineering (hooks)

**Why now.** "I told the agent not to" is not enforcement; agents find the cheapest path to green, sometimes a destructive one.
**What good looks like.** A hook or approval gate makes the dangerous action impossible without a human.
**How to check.** Is there anything technical (not just a rule) stopping an agent force-pushing or dropping a table?
**Failure modes.** Relying on a polite line in `AGENTS.md` to prevent disasters.

---

## 7. Comprehension & Judgment

### I form an independent expectation of the answer *before* reading the agent's output, so I notice when they diverge
`S2` · `comprehension` `surrender` · **Concept:** Cognitive Surrender

**Why now.** Constructing your own expectation first is what keeps you on the offloading side of the line, not the surrender side.
**What good looks like.** You jot (even mentally) what the answer should be before you run the agent.
**How to check.** On your last task, did you have a prediction to compare the output against?
**Failure modes.** Adopting the model's framing and answer in the same gesture.

### I can explain, in my own words, any non-obvious line I'm about to merge — or I don't merge it yet
`S2` · `comprehension` · **Concept:** Comprehension Debt

**Why now.** "Reviewed" must mean "understood"; the gap between them is where comprehension debt accrues.
**What good looks like.** You could debug the change without the agent transcript.
**How to check.** Point at a random non-obvious line in your last PR — can you explain why it's there?
**Failure modes.** Approving code you couldn't reconstruct or debug alone.

### When learning something new I ask the agent to *explain* before I ask it to *generate*
`S2` · `comprehension` `learning` · **Concept:** Cognitive Surrender / Comprehension Debt

**Why now.** In a controlled trial, engineers who used AI for inquiry held their comprehension; those who used it to generate scored markedly lower. Same tool, different posture.
**What good looks like.** New libraries/systems start with questions, not "write it for me."
**How to check.** When you last learned something new, did you interrogate or just delegate?
**Failure modes.** "Just make it work" while learning, then owning code you don't understand.

### I notice fatigue and stop letting agents generate when I'm too tired to evaluate
`S3` · `surrender` · **Concept:** Cognitive Surrender

**Why now.** Surrender is a fatigue phenomenon — the first PR of the day gets a real review; the fifth gets a glance.
**What good looks like.** You stop generating when you can't evaluate, and resume when you can.
**How to check.** Do your worst merges cluster at the end of long sessions?
**Failure modes.** Pushing through tired, rubber-stamping to finish.

### When I catch myself defending a design I can't reconstruct, I rebuild the *why* before continuing
`S3` · `surrender` `intent` · **Concept:** Cognitive Surrender / Intent Debt

**Why now.** Defending a choice you can only attribute to "the agent suggested it" is borrowed confidence — a surrender artifact.
**What good looks like.** You go back to the code and rebuild the reasoning before the conversation moves on.
**How to check.** In your last design discussion, could you reconstruct every choice you advocated?
**Failure modes.** Carrying the model's certainty without its (nonexistent) reasoning.

### I keep some solo, agent-free coding time as a calibration check on my own skills
`S3` · `comprehension` · **Concept:** Cognitive Surrender

**Why now.** The day you can't comfortably build something simple without AI is the day offloading became surrender and you didn't notice.
**What good looks like.** Regular, deliberate solo reps — not as penance, as calibration.
**How to check.** When did you last build something non-trivial without an agent?
**Failure modes.** Total dependence creeping in unmeasured.

---

## 8. Reusable Capability & the Ratchet

### When I hit the same problem twice, I package the fix as a skill, command, or rule instead of re-solving it
`S3` · `ratchet` `skills` · **Concept:** Loop Engineering (skills)

**Why now.** A skill is intent written down once where the agent reads it every run, so the loop stops re-deriving your project from zero.
**What good looks like.** The second occurrence of a problem is cheaper because you captured the first.
**How to check.** What did you turn into a skill/rule after solving it twice recently?
**Failure modes.** Re-explaining the same context every session like a goldfish.

### Every time an agent makes a real mistake, I add a durable guard (an `AGENTS.md` line, a hook, a reviewer check) so it can't recur
`S4` · `ratchet` · **Concept:** Harness Engineering (the ratchet)

**Why now.** Mistakes are signals, not one-offs; the ratchet is the habit that turns each into a permanent fix.
**What good looks like.** Recurring failures disappear because you closed them off structurally.
**How to check.** Trace a recent rule or hook back — was it born from a specific failure?
**Failure modes.** Laughing off "bad runs" and retrying instead of ratcheting.

### I treat skills, rules, and hooks as code — versioned, reviewed, and *removed* when a better model makes them redundant
`S4` · `ratchet` `skills` · **Concept:** Harness Engineering

**Why now.** A harness is a living system; constraints that a capable model has made redundant are now noise competing for attention.
**What good looks like.** Your scaffolding is in git, reviewed, and pruned as models improve.
**How to check.** When did you last *delete* a rule because it was no longer needed?
**Failure modes.** Accreting rules forever; dead anxiety-scaffolding nobody removes.

### I write hooks so success is silent and failure is verbose — the error feeds back into the loop for self-correction
`S4` · `harness` `hooks` · **Concept:** Harness Engineering (hooks)

**Why now.** Silent success / verbose failure makes the feedback loop almost free in the common case and directly actionable when something breaks.
**What good looks like.** Passing checks say nothing; failing ones inject the error so the agent self-corrects.
**How to check.** Do your hooks stay quiet on success and loud (and specific) on failure?
**Failure modes.** Noisy hooks you learn to ignore; failures that don't reach the agent.

### I contribute reusable learnings back to the shared library, not just my private notes
`S3` · `ratchet` `knowledge` · **Concept:** Loop Engineering / Intent Debt

**Why now.** Knowledge kept in DMs doesn't compound; the next person (or agent) rediscovers the same fix.
**What good looks like.** Your learnings land in shared rules/skills via PR, not a private file.
**How to check.** Git history on the shared skills/rules for your contributions this month.
**Failure modes.** Prompts and fixes hoarded in personal notes.

### I keep `AGENTS.md` short and earn each line — every rule traces to a real failure or a hard constraint
`S3` · `harness` `ratchet` · **Concept:** Harness Engineering

**Why now.** Every line competes for the model's attention; more rules make each rule matter less. Pilot's checklist, not a style guide.
**What good looks like.** A tight file where each line has a reason behind it.
**How to check.** Read your `AGENTS.md` — could you justify every line, and is it short?
**Failure modes.** A sprawling rulebook of brainstormed "best practices."

---

## 9. Measurement, Cost & Compounding

### I watch my own signals — revert / rework rate, time-to-merge, how often my AI PRs need follow-up — and adjust when patterns emerge
`S3` · `metrics` · **Concept:** Verification Bottleneck

**Why now.** Raw output overstates value (~4× code for ~12% more value); your own rework rate tells you the real story.
**What good looks like.** You track a couple of personal signals and change your workflow when they move.
**How to check.** Can you name your rough revert/rework rate on AI-assisted work?
**Failure modes.** Measuring nothing; equating "more PRs" with "more value."

### I review my token / cost usage periodically and trim wasteful loops
`S2` · `cost` · **Concept:** Loop Engineering (cost caution)

**Why now.** Loop and multi-agent usage can vary wildly; cost discipline keeps the practice sustainable.
**What good looks like.** A recurring glance at spend and a habit of cutting wasteful runs.
**How to check.** Do you know roughly what your AI usage costs and where it goes?
**Failure modes.** Always-on max-model habits; unbounded loops burning tokens.

### When a result goes wrong I replay the run and inspect its tool calls and decisions, not only the code it left behind
`S3` · `observability` · **Concept:** Harness Engineering (observability)

**Why now.** The bug is often in a wrong tool call or a bad assumption mid-run, invisible in the final diff.
**What good looks like.** You inspect the tool-call sequence and decisions, not only the output.
**How to check.** On your last incident, did you read the trace or just the code?
**Failure modes.** Debugging the symptom without seeing how the agent got there.

### I update prompt / skill evaluations whenever I change a rule or skill, so I don't regress silently
`S4` · `evals` · **Concept:** Self-Improving Loops

**Why now.** Skills and prompts are code; without evals you regress invisibly when you tweak them.
**What good looks like.** Changing a skill triggers an eval update, like changing code triggers a test.
**How to check.** Does your most-used skill have any regression check at all?
**Failure modes.** Editing a rule and hoping it still behaves.

### I attribute AI authorship per my project's policy and respect its IP / provenance rules for generated code
`S2` · `governance` · **Concept:** Factory Model (provenance)

**Why now.** Provenance and IP rules for generated code are increasingly a compliance reality, not a nicety.
**What good looks like.** Your commits/PRs follow the project's attribution and third-party-code policy.
**How to check.** Do your recent AI-assisted commits meet the project's policy?
**Failure modes.** Silent AI authorship; ignoring provenance rules.

### I can tell whether my understanding of the system is growing or shrinking as I ship — and treat shrinking as a debt to pay
`S4` · `comprehension` `compounding` · **Concept:** Cognitive Surrender / Comprehension Debt

**Why now.** If code ships and your understanding shrinks, you're paying in cognitive debt; if it grows, you're doing the actual job, faster.
**What good looks like.** You can honestly say your mental model is sharpening over time, not eroding.
**How to check.** After your last sprint, did you understand the system better or worse?
**Failure modes.** Shipping fast while quietly losing the thread of your own codebase.

---

*58 entries — the companion guide to the Personal checklist.*