--- framework: Agentic Engineering Maturity — Factory Edition version: 2026.06.0 kind: checklist lens: personal title: Personal Checklist --- # Personal Checklist **Version `2026.06.0`** · Score one engineer's habits and judgment. **Name:** ________________________________ **Date:** ________________ **Assessed by:** ________________________ Each item carries a **stage** (`S0`–`S4`) and **theme tags**. You are at a stage within a dimension when you satisfy its items *consistently* — across your recent work, not once. Your overall stage is the lowest that holds across the dimensions you treat as load-bearing. See the companion guide for the *why*, *what good looks like*, and *how to check* behind every item. > Stages: **S0** Improvised · **S1** Assisted · **S2** Delegated · **S3** Orchestrated · **S4** Autonomous Agents --- ## 1. Intent & Specification *Is the why written down before the agent runs?* - [ ] Before non-trivial work I write the intent down — goals, constraints, and an explicit definition of done — not just the task `S2` `intent` `spec` - [ ] I specify outcomes and let the agent propose the implementation — I keep the *what/why* separate from the *how* `S2` `spec` - [ ] When the agent surfaces an unknown, I update the spec, not only the code `S2` `spec` `intent` - [ ] For load-bearing decisions I record the *why* (a short decision note / ADR) the moment I make it, so the rationale outlives my memory `S3` `intent` `decision-log` - [ ] My specs are written so an agent can act on them *and* a reviewer can evaluate against them `S2` `spec` `review` - [ ] I refuse to start from a vague spec — I sharpen "make it work" into measurable outcomes before any code is generated `S2` `spec` `quality` - [ ] My definition of done names the non-negotiables for this change (performance, accessibility, security), not just "it functions" `S3` `spec` `quality` ## 2. Context, Memory & Harness *Does the agent get the right context and durable memory — without rot?* - [ ] I attach the specific files, types, and examples a task needs and strip the noise — not a whole-codebase dump `S2` `context` - [ ] I notice when the agent starts guessing and add context instead of telling it to push on `S2` `context` `quality` - [ ] I keep durable memory outside the chat (a task/progress file, notes in `AGENTS.md`) so work survives a context reset `S3` `harness` `memory` - [ ] I treat `AGENTS.md` / rules as an intent ledger — conventions and "we don't do X because…", not autogenerated boilerplate `S3` `harness` `intent` - [ ] 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` - [ ] When the model underperforms I tune my own harness (prompts, tools, ignore files) instead of only waiting for a better model `S3` `harness` - [ ] I keep the agent's tool/skill menu small and relevant to the task at hand `S2` `harness` `tooling` ## 3. Loops, Autonomy & Orchestration *Am I designing systems that prompt agents — or hand-prompting one turn at a time?* - [ ] I match autonomy to risk per task (suggest / apply-with-confirm / apply / merge) rather than defaulting to max autonomy `S2` `autonomy` - [ ] For repeatable work I build a small loop (automation + checker + state file) instead of re-prompting by hand each time `S4` `loop` - [ ] 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` - [ ] 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` - [ ] I scale my fleet to my review rate, batch my reviews, and protect uninterrupted time for judgment-heavy work `S3` `orchestration-tax` - [ ] 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` - [ ] I give long-running agents explicit stop conditions and a verifiable "done," not an open-ended goal `S3` `loop` `autonomy` ## 4. Verification & Review *Is my review tiered, adversarial, evidence-gated, and owned at merge?* - [ ] 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` - [ ] I read AI-generated diffs as if a junior wrote them; "the tests pass" is never the whole review `S2` `review` `comprehension` - [ ] I read the *test* changes more carefully than the code, watching for assertions rewritten to match broken behavior `S3` `review` `testing` - [ ] 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` - [ ] I never merge just to clear a queue — when I click merge, I own it `S2` `review` `accountability` - [ ] 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` - [ ] I keep my PRs small on purpose, instructing agents to produce reviewable commits `S2` `review` `quality` ## 5. Tests & Deterministic Gates *Do real tests and gates carry the weight human reading no longer can?* - [ ] I add or update real tests in the same change as the code — never "tests later" `S2` `testing` - [ ] For non-trivial logic I write (or confirm) the tests before the implementation and check they fail first `S3` `testing` `tdd` - [ ] 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` - [ ] I lean on deterministic gates (types, lint, tests) to carry load human reading can't, and I keep them green *honestly* `S2` `testing` `gates` - [ ] I use mutation testing or targeted checks where "coverage is green" isn't enough to trust the suite `S4` `testing` `quality` - [ ] 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` ## 6. Safety, Security & Guardrails *Are dangerous actions blocked by construction, not by hope?* - [ ] Real credentials, customer data, and production keys stay out of every prompt — I work with synthetic stand-ins instead `S1` `security` - [ ] I scope tool permissions per project (file, terminal, network, MCP) and don't run "allow all" against prod-adjacent work `S2` `security` `permissions` - [ ] I run agent-executed code in a sandbox / ephemeral environment, especially when untrusted input is involved `S3` `security` `sandbox` - [ ] 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` - [ ] 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` - [ ] I keep destructive operations behind a confirmation or block (force-push, prod migration, mass delete), not just an instruction `S3` `security` `guardrails` ## 7. Comprehension & Judgment *Do I still understand what ships — or am I surrendering the thinking?* - [ ] I form an independent expectation of the answer *before* reading the agent's output, so I notice when they diverge `S2` `comprehension` `surrender` - [ ] 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` - [ ] When learning something new I ask the agent to *explain* before I ask it to *generate* `S2` `comprehension` `learning` - [ ] I notice fatigue and stop letting agents generate when I'm too tired to evaluate `S3` `surrender` - [ ] When I catch myself defending a design I can't reconstruct, I rebuild the *why* before continuing `S3` `surrender` `intent` - [ ] I keep some solo, agent-free coding time as a calibration check on my own skills `S3` `comprehension` ## 8. Reusable Capability & the Ratchet *Does every mistake become a permanent rule, skill, or hook?* - [ ] 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` - [ ] 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` - [ ] I treat skills, rules, and hooks as code — versioned, reviewed, and *removed* when a better model makes them redundant `S4` `ratchet` `skills` - [ ] I write hooks so success is silent and failure is verbose — the error feeds back into the loop for self-correction `S4` `harness` `hooks` - [ ] I contribute reusable learnings back to the shared library, not just my private notes `S3` `ratchet` `knowledge` - [ ] I keep `AGENTS.md` short and earn each line — every rule traces to a real failure or a hard constraint `S3` `harness` `ratchet` ## 9. Measurement, Cost & Compounding *Can I tell the factory is getting better, not just faster?* - [ ] 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` - [ ] I review my token / cost usage periodically and trim wasteful loops `S2` `cost` - [ ] 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` - [ ] I update prompt / skill evaluations whenever I change a rule or skill, so I don't regress silently `S4` `evals` - [ ] I attribute AI authorship per my project's policy and respect its IP / provenance rules for generated code `S2` `governance` - [ ] 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` --- *58 items across 9 dimensions. Pair with the companion guide for the "why," "what good looks like," and "how to check" behind each.*