Matt Pocock — Agent-Engineering Field Guide

A practitioner's extraction of the high-ticket, implementable ideas from Matt Pocock's (@mattpocockuk) AI-engineering era (~late 2025 → mid 2026), focused on Claude Code / agent power-user leverage. Every non-obvious claim carries a source URL. Items I could not verify from a primary source are marked [UNVERIFIED].

Why he's a signal source

Matt Pocock built Total TypeScript (the reference TS course) and then pivoted to AI engineering via aihero.dev. That lineage matters: he approaches agents as a software-engineering-fundamentals problem, not a prompt-hacking one. His core thesis — "software engineering fundamentals are not obsolete; they're the leverage layer that makes AI agents useful" — is the opposite of vibe-coding, and it's backed by concrete, open-source tooling you can install and run today:

• mattpocock/skills — his actual .claude skill directory, open-sourced, composable, model-agnostic. Install: npx skills@latest add mattpocock/skills. Repo: <github.com/mattpocock/skills>
• mattpocock/evalite — a TypeScript-native eval runner ("Vitest for LLM apps"). Repo: <github.com/mattpocock/evalite> · Docs: <evalite.dev>
• aihero.dev — courses/workshops on AI SDK, agents, evals, Claude Code. <aihero.dev>

The reason to mine him specifically: he has productized the agent workflow into small, inspectable skills that encode named engineering disciplines. You can read the source, cherry-pick the mental models, and adapt the exact skills. This is the rare "creator" whose output is directly forkable into a power-user's .claude directory.

Primary corpus swept: the mattpocock/skills repo (README + individual SKILL.md files, read via gh api), mattpocock/evalite, aihero.dev posts/workshops, and his X. Secondary write-ups (explainX, Medium, knightli, InfoQ) are cited where they capture claims I could not pull from a primary source — flagged inline.

1. The governing thesis: constrain freedom, not capability

His central disagreement with the "move fast" school: the problem was never model capability — it's unguided autonomy.

• "The cheaper code generation becomes, the more costly unclear requirements become." Bad code used to take time to write; now hundreds of unvalidated lines materialize instantly. Source (secondary): <knightli.com/en/2026/05/15/matt-pocock-skills-ai-engineering
• "What really needs limiting is freedom" — the model should operate inside human-defined boundaries: problem scope, architecture, acceptance criteria, and domain language. Same source.
• Quality Amplification Principle: "AI agents amplify whatever system you give them." Clear requirements → aligned output; vague requirements → misguided output — bidirectionally, so a broken process now accelerates at machine speed. Source: <explainx.ai/blog/matt-pocock-ai-coding-real-engineers-worksh
• Sharp take on where the skill gap lands: "The gap will be between people who can put AI inside a maintainable, verifiable, evolving engineering system and those who cannot." Source: knightli (above).

Why he built the skills at all — he names four failure modes and maps each to a skill (from the repo README, <github.com/mattpocock/skills>):

1. "The agent didn't do what I want" (misalignment) → /grill-me, /grill-with-docs
2. "The agent is way too verbose" (no shared language) → CONTEXT.md / domain modeling
3. "The code doesn't work" (no feedback loops) → /tdd, /diagnosing-bugs
4. "We built a ball of mud" (entropy accelerates with agents) → /improve-codebase-architecture, /codebase-design

He explicitly positions these against heavier frameworks: "Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve." His skills are deliberately small, adaptable, composable, model-agnostic. Source: repo README.

2. Context engineering — the smart zone / dumb zone

The single most-cited technique. It's a concrete, numeric mental model for context budgeting.

• Smart zone vs. dumb zone: LLM reasoning quality degrades sharply once context passes 100,000 tokens (40% of a 256k window). Beyond that "smart zone" the model enters the "dumb zone" — attention scales quadratically, so reasoning rots as the window fills. Source (secondary, from his workshop): <explainx.ai/blog/matt-pocock-ai-coding-real-engineers-worksh
• Implication for practice: don't run one long conversation. Decompose work across multiple focused conversations — each phase (align → plan → implement → review) runs in isolation with only its relevant context. Give the agent only issue-specific code, not the whole codebase. Use a fresh context for code review to avoid anchoring bias. Source: same.
• Cross-ref: this is the same insight as the wider "context engineering" literature (context rot, needle-in-haystack degradation) and the loops corpus on keeping context lean — Pocock's contribution is the actionable 100k/40% budget line and the discipline of one-conversation-per-phase.

2a. Shared language (CONTEXT.md) — "the single coolest technique in this repo"

The fix for verbosity failure mode #2 is a ubiquitous language doc (Eric Evans / DDD), maintained by the /grill-with-docs and /domain-modeling skills.

• CONTEXT.md is a living glossary of project vocabulary. His example: rewriting "a problem when a lesson inside a section of a course is made 'real' (given a spot in the file system)" down to "a problem with the materialization cascade." Source: repo README, example from <github.com/mattpocock/course-video-manager>
• Payoffs he names: (1) variables/functions/files get named consistently using the shared language; (2) the codebase becomes easier for the agent to navigate; (3) the agent spends fewer tokens on thinking because it reasons in a more concise language. Source: repo README.
• The domain-modeling skill also writes ADRs (Architecture Decision Records) inline to capture hard-to-explain decisions. Skill: skills/engineering/domain-modeling/SKILL.md (with CONTEXT-FORMAT.md + ADR-FORMAT.md).
• This is a leading word technique (see §11): a compact coined term ("materialization cascade") recruits the model's priors and anchors a whole region of behavior in one token.

2b. Handoffs — compacting context across sessions

Skill: skills/productivity/handoff/SKILL.md. Compact the current conversation into a handoff doc so a fresh agent continues cleanly (the practical answer to the dumb-zone: reset context, carry a summary). Rules from the skill:

• Save to the OS temp directory, not the workspace.
• Include a "suggested skills" section telling the next agent which skills to invoke.
• Don't duplicate content already in PRDs/plans/ADRs/issues/commits — reference by path/URL.
• Redact secrets/PII.

Cross-ref: this is exactly the handoff-doc pattern the user's own doctrine uses (handoffs/RUN-STATE.md, run-contract handoffs) — Pocock's version is a portable skill.

3. Alignment before code — the grilling pattern (his most popular skills)

Fixes failure mode #1. Force the agent to interrogate you before it writes anything.

• /grill-me (skills/productivity/grill-me/SKILL.md) and /grill-with-docs (skills/engineering/grill-with-docs/SKILL.md) run a relentless interview until every branch of the decision tree is resolved. The reusable engine is skills/productivity/grilling/SKILL.md.
• Discipline: one question at a time, each with a recommended answer attached (from the loop-me skill's description of grilling). It surfaces edge cases, architecture constraints, perf requirements, testing strategy, integration points — the workshop cites 16–50 (some sources say 40–80) questions per session. Source: <adityakumarpuri.medium.com/matt-pococks-5-claude-code-skills and explainX.
• Intellectual lineage he cites: Frederick Brooks, The Design of Design; Pragmatic Programmer's "No-one knows exactly what they want." Source: repo README + Medium.
• Why it's high-ticket: it prevents hours of wasted autonomous work by catching misunderstanding before generation — the cheapest possible place to catch it.

4. Spec → PRD → issues → vertical slices

The pipeline that turns a grilling session into agent-executable work.

• /to-prd (skills/engineering/to-prd/SKILL.md): synthesizes the conversation into a PRD (problem statement, success criteria, user stories in "As a [user], I want [capability], so I can [benefit]" form). No new interview — it just crystallizes what was discussed. It also quizzes you on which modules you're touching and flags deep modules. Source: repo README + Medium.
• /to-issues (skills/engineering/to-issues/SKILL.md): breaks the plan into tracer-bullet vertical slices.

Vertical slices (tracer bullets) — the core decomposition rule

Each issue is a thin vertical slice cutting through ALL layers end-to-end (schema + API + UI + tests), not a horizontal slice of one layer. Rules from the skill:

• Each slice delivers a narrow but complete path through every layer, and is demoable/verifiable on its own.
• Prefactor first: "Make the change easy, then make the easy change." (Kent Beck)
• Each issue gets a ## Blocked by dependency edge and an acceptance-criteria checklist.
• Avoid file paths / code snippets in issue bodies — "they go stale fast." Exception: point to a /prototype-produced artifact (state machine, reducer, schema) rather than inlining it.

Wide refactors — the exception (expand–contract)

A wide refactor (rename a column, retype a shared symbol) has a blast radius that breaks thousands of call sites at once — no vertical slice can land green. Don't force it into a tracer bullet; sequence it as expand → migrate in batches → contract:

1. Expand: add the new form beside the old so nothing breaks.
2. Migrate: convert call sites in batches sized by blast radius (per package/dir), each its own issue, CI green throughout because the old form still exists.
3. Contract: delete the old form once no caller remains, blocked by every migrate batch. When even batches can't stay green alone, share an integration branch that all block a final integrate-and-verify issue. Source: skills/engineering/to-issues/SKILL.md.

HITL vs. AFK classification

Every issue is tagged HITL (human-in-the-loop — needs judgment, architecture, business tradeoffs) or AFK (away-from-keyboard — well-defined, testable, isolated, safe for autonomous work). Only AFK issues are safe to hand to an unattended agent. Source: explainX + Medium. Cross-ref: this is the same "closed-loop, hard-cap, proof-gated" discipline the user's /goal doctrine enforces.

5. Feedback loops — TDD and the debugging discipline

Fixes failure mode #3. This is arguably his sharpest agent-engineering contribution: the feedback loop is the whole game.

/tdd — red-green, one vertical slice at a time

Skill: skills/engineering/tdd/SKILL.md.

• Seams: a seam is the public boundary you test at. Test only at pre-agreed seams — write down the seams under test and confirm with the user before writing any test. "You can't test everything — agreeing the seams up front is how testing effort lands on the critical paths."
• A good test reads like a specification ("user can checkout with valid cart") and survives refactors because it tests behavior through public interfaces, not internals.
• Three named anti-patterns:
  • Implementation-coupled — mocks internal collaborators / tests private methods / queries the DB instead of the interface. Tell: breaks on refactor though behavior didn't change.
  • Tautological — the assertion recomputes the expected value the way the code does (expect(add(a,b)).toBe(a+b)); it can never disagree with the code. Expected values must come from an independent source of truth.
  • Horizontal slicing — writing all tests then all implementation; bulk tests verify imagined behavior. Work in vertical slices: one test → one implementation → repeat, each a tracer bullet reacting to what the last cycle taught you.
• Rules of the loop: red before green; one seam/test/minimal-implementation per cycle; refactoring is NOT part of the loop — it belongs to the review stage.
• Reads CONTEXT.md first so test names match domain vocabulary.

/diagnosing-bugs — "build the feedback loop; the bug is 90% fixed"

Skill: skills/engineering/diagnosing-bugs/SKILL.md. A 6-phase discipline where Phase 1 IS the skill:

• Phase 1 — build a tight, red-capable feedback loop. "If you have a tight pass/fail signal that goes red on this bug, you will find the cause… If you don't, no amount of staring at code will save you." A ranked ladder of ways to construct one: failing test → curl/HTTP script → CLI+fixture diff → headless browser script → replay a captured trace → throwaway harness → property/fuzz loop → bisection harness (git bisect run) → differential loop (old vs new) → HITL bash script (last resort, via scripts/hitl-loop.template.sh).
• Tighten the loop (treat it as a product): faster (cache setup, narrow scope), sharper signal (assert the specific symptom, not "didn't crash"), more deterministic (pin time, seed RNG, isolate FS, freeze network). "A 30-second flaky loop is barely better than no loop; a 2-second deterministic one is a debugging superpower."
• Non-deterministic bugs: goal is a higher reproduction rate, not a clean repro — loop the trigger 100×, parallelize, add stress, inject sleeps. "A 50%-flake bug is debuggable; 1% is not."
• Hard gate: Phase 1 is done only when you can name one command you've already run that is red-capable + deterministic + fast + agent-runnable. "If you catch yourself reading code to build a theory before this command exists, stop."
• Phases 2–6: reproduce + minimise (shrink to smallest still-red scenario) → 3–5 ranked falsifiable hypotheses (each states a prediction; show the list to the user before testing) → instrument (one variable at a time; prefer debugger over logs; tag every debug log with a unique prefix like [DEBUG-a4f2] so cleanup is one grep) → fix + regression test at a correct seam (if no correct seam exists, that's the finding — hand to /improve-codebase-architecture) → cleanup + post-mortem (state the correct hypothesis in the commit; "what would have prevented this?").

Why high-ticket: this is a directly-installable replacement for the flailing "read code, guess, patch, repeat" loop most agents fall into. The "build the loop first" gate is the durable insight.

6. Codebase design — deep modules & seams

Fixes failure mode #4 ("ball of mud"). Skill: skills/engineering/codebase-design/SKILL.md. A precise, enforced vocabulary (John Ousterhout + Michael Feathers, but reframed):

• Deep module = small interface + lots of implementation (favor this). Shallow module = large interface + thin implementation (avoid). Depth = leverage at the interface: behavior a caller/test can exercise per unit of interface they must learn.
• Interface = everything a caller must know: type signature plus invariants, ordering constraints, error modes, required config, perf characteristics. (Deliberately broader than "API"/"signature".)
• Seam (Feathers) = a place you can alter behavior without editing in that place; where the interface lives — its own design decision, distinct from what goes behind it. He insists on "seam" over "boundary" (overloaded by DDD).
• The deletion test: imagine deleting the module. If complexity vanishes, it was a pass-through; if complexity reappears across N callers, it earned its keep. Also: "One adapter = a hypothetical seam. Two adapters = a real one." Don't introduce a seam unless something actually varies across it.
• Design for testability: accept dependencies (don't new them inside); return results (don't mutate); small surface area. "The interface is the test surface" — if you need to test past the interface, the module is the wrong shape.
• He rejects Ousterhout's depth-as-line-ratio ("rewards padding the implementation") in favor of depth-as-leverage.
• /improve-codebase-architecture scans for "deepening opportunities," renders a visual HTML report, and grills you through the one you pick. He recommends running it every few days. (Cross-ref: matches the user's "HTML artifacts over markdown for anything a human reads" doctrine.)
• DESIGN-IT-TWICE.md: spin up parallel sub-agents to design the same interface several radically different ways, then compare on depth/locality/seam placement.

7. Code review — two axes, parallel sub-agents, no cross-ranking

Skill: skills/engineering/code-review/SKILL.md. A genuinely clever harness pattern:

• Reviews the diff (git diff <fixed-point>...HEAD, three-dot so it's against the merge-base) along two independent axes, each run in a parallel general-purpose sub-agent so they don't pollute each other's context:
  • Standards — does it follow the repo's documented standards, plus a fixed Fowler code-smell baseline (from Refactoring ch.3) that applies even when the repo documents nothing? The 12 smells are pasted into the sub-agent prompt verbatim (Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Repeated Switches, Shotgun Surgery, Divergent Change, Speculative Generality, Message Chains, Middle Man, Refused Bequest — each with a fix). The repo overrides the baseline; smells are always judgement calls; skip anything tooling already enforces.
  • Spec — does the diff faithfully implement the originating issue/PRD? Reports missing requirements, scope creep, and wrong-looking implementations, quoting the spec line for each.
• Deliberately never merges or re-ranks the two axes' findings — "reporting them separately stops one axis from masking the other." A change can pass Standards but fail Spec (right conventions, wrong thing) or vice versa.
• Each sub-agent is capped at <400 words.

Model routing for review (from the workshop write-up, secondary): implementation on Sonnet (speed/cost, follows spec), review on Opus (reasoning, architectural judgment, subtle bugs), reviewer always in fresh context with an explicit checklist that lists issues before praise. Source: <explainx.ai/blog/matt-pocock-ai-coding-real-engineers-worksh (Cross-ref: identical shape to the user's own Sonnet-executor / Opus-reviewer seat doctrine and the built-in /review fan-out.)

8. Autonomous agent loops & safety

• The Ralph loop (continuous autonomous work, from the workshop, secondary): a bash-driven pattern where the agent reads state from disk (issues, tests, last commit), picks the next AFK issue from a prioritized backlog, implements + validates via tests, commits on success, exits on failure — re-running until it hits ambiguity or a blocker. Appropriate only for a backlog with comprehensive tests, low-risk changes, cost-insensitive contexts. Not for exploratory work, untested code, or security/payment/data-integrity changes. Source: explainX. (In-repo, the WIP skills/in-progress/loop-me/SKILL.md and wizard/template.sh are the spec-building side of this.)
• Sand Castle framework (parallel execution, workshop, secondary): orchestrates multiple sandboxed agents via git worktrees + Docker containers, with agent roles (planner / implementation / reviewer / merger), timeout enforcement, and automated cleanup — claimed 3–5× faster delivery for well-specified work. Source: explainX. [Naming UNVERIFIED against a primary source] — treat "Sand Castle" as the workshop's label; the underlying worktree+container+role pattern is standard and matches the user's own worktree-backed background-subagent model.
• loop-me (skills/in-progress/loop-me/SKILL.md) — the "loops within loops" lens for finding delegatable recurring work, and building workflow specs. Key vocabulary worth stealing: Trigger (event vs schedule — "event-triggering is usually more efficient"), Checkpoint (a HITL verify/decide point; some workflows have none), Push right ("defer the checkpoint as far as it will go — do maximal work before involving the human, so they're asked once, late, with everything prepared"), Brief ("a decision-ready summary… the user reads a brief, not a draft"). Cross-ref: near-identical to the user's /goal "push-right + decision-ready brief" doctrine.
• git-guardrails-claude-code (skills/misc/git-guardrails-claude-code/SKILL.md): a PreToolUse hook that blocks dangerous git before it executes — git push (incl. --force), reset --hard, clean -f/-fd, branch -D, checkout ./restore .. The blocked agent is told it "does not have authority" to use these. Exit code 2 + stderr message. Cross-ref: exactly the user's "enforcement is a hook, never prose" doctrine — Pocock ships a ready-made version.

9. Evals & Evalite — eval-driven development in TypeScript

His biggest standalone tool. Evalite = "Vitest/Jest for LLM-powered apps" — local-first, TypeScript-native, built on Vitest with .eval.ts files, a web UI, tracing, and cost-awareness. Repo: <github.com/mattpocock/evalite> · Docs: <evalite.dev> · Scorers guide: <evalite.dev/guides/scorers> · InfoQ intro: <infoq.com/news/2025/11/evalite-ai-testing/>

Evalite v1 (preview post: <aihero.dev/evalite-v1-preview>) ships 10 built-in scorers, each returning a 0–1 score:

• String (deterministic): exactMatch, contains, levenshtein (fuzzy — good for SQL/code where formatting varies).
• RAG (LLM-as-judge): faithfulness (hallucination detection — is output grounded in context?), answerSimilarity (semantic alignment), answerCorrectness (factual vs ground truth), answerRelevancy (does it actually answer the question?), contextRecall (was all relevant context retrieved?).
• Advanced: toolCallAccuracy (did the agent call the right tools with the right args?), noiseSensitivity (inject noise, verify consistency).

Architecture worth noting:

• wrapAISDKModel() instruments any Vercel AI SDK model across generateText/streamText/generateObject/streamObject for automatic tracing + full pipeline caching (both task and scorer models cache), and is a no-op in production ("zero overhead").
• In-memory storage by default in v1 (optional SQLite for persistence) — removes setup friction.
• Watch mode: change scorer logic without re-running cached LLM calls.

Eval-Driven Development (EDD) is a named module in his AI SDK course — using evals to "stamp out hallucinations," picking which model performs best for a use case, and finding edge cases that trip tool-calling agents. Workshops: <aihero.dev/workshops/evals-project-21d8s>, <aihero.dev/workshops/evals-skill-building-j36oe>. He's publicly aiming for Evalite to become "THE evals tool for the AI SDK": <x.com/mattpocockuk/status/1980685949609865695>.

Cross-ref: this is the concrete "evals" layer of the LangChain-levels / harness-design literature — Pocock's differentiator is that it's TS-native, local-first, and rides the AI SDK you'd already be using.

10. The Vercel AI SDK track

Not agent-harness per se, but the substrate he builds agents on. AI SDK v6 Crash Course (94 videos / 59 exercises / 10 modules): <aihero.dev/workshops/ai-sdk-v6-crash-course>. Covers LLM fundamentals, agents & tool-calling as core design patterns, production-ready tool design, model guardrails, generator/evaluator workflows, a research agent, and Eval-Driven Development. His X summary of the (v5) curriculum: <x.com/mattpocockuk/status/1978434443523084671>. Takeaway for a Claude Code power user: he treats tool-calling agents and workflows as first-class, evaluable design patterns — every tool/agent gets an eval, not just a prompt.

11. Meta: writing great skills (how to build your own .claude)

The most transferable document for a power user is skills/productivity/writing-great-skills/SKILL.md — his theory of skill authorship. Steal these:

• A skill exists to wrangle determinism out of a stochastic system. Predictability — the agent taking the same process every run — is the root virtue.
• Two invocation modes, two costs: model-invoked skills keep a description (agent can auto-fire; other skills can reach it) but pay context load (the description sits in the window every turn); user-invoked skills (disable-model-invocation: true) have zero context load but spend cognitive load (you must remember they exist). When user-invoked skills pile up, add a router skill (his is /ask-matt).
• Information hierarchy / progressive disclosure: three tiers — in-skill step (ordered action, ends on a checkable completion criterion), in-skill reference (consulted on demand), external reference (pushed to a linked file behind a context pointer, loaded only when needed). "Inline what every branch needs; push behind a pointer what only some branches reach."
• Leading words: a compact concept already in the model's pretraining (lesson, tracer bullet, fog of war, tight loop, red) that anchors a whole region of behavior in the fewest tokens by recruiting priors. It works twice — anchors execution in the body and invocation in the description when the same word lives in your prompts/docs/code. "Assume every skill is carrying restatements that leading words retire."
• Failure modes to hunt: premature completion (fix by sharpening the completion criterion first, then hide post-completion steps by splitting), duplication, sediment (stale layers — the default fate without a pruning discipline), sprawl (too long even if every line is live — cure with the disclosure ladder), no-op (a line the model already obeys by default — pay tokens to say nothing), negation ("don't think of an elephant" backfires — prompt the positive; keep a prohibition only as a hard guardrail and pair it with what to do instead).
• Pruning discipline: single source of truth per meaning; check every line for relevance; hunt no-ops sentence by sentence and delete the whole sentence, don't trim words. "Be aggressive — most prose that fails should go, not be rewritten."

This section alone is a field guide for improving the user's own extensive .claude skill collection.

Tooling & source index

Provenance note: everything in §§2a, 2b, 3–9, 11 is pulled from primary sources (the repo's SKILL.md files read via gh api, or aihero.dev/GitHub pages). Numeric/naming claims that appear only in secondary write-ups — the 100k/40% dumb-zone threshold, "Ralph loop," "Sand Castle," Sonnet-impl/Opus-review routing, question counts — are flagged inline as such. A widely-repeated "135,000+ GitHub stars" figure for the skills repo appears only in low-trust secondary sources and is [UNVERIFIED] (the repo README itself only cites ~60,000 newsletter subscribers).

High-ticket action items (build/adopt these)

1. Install mattpocock/skills and cherry-pick. npx skills@latest add mattpocock/skills. Highest-value grabs: grill-with-docs (alignment + CONTEXT.md), diagnosing-bugs (the feedback-loop gate), code-review (two-axis parallel sub-agents), tdd. All model-agnostic — read the SKILL.md, adapt to Opus/Sonnet. <github.com/mattpocock/skills>
2. Adopt the CONTEXT.md shared-language doc per repo. A living glossary of coined domain terms ("materialization cascade") that cuts agent verbosity, standardizes naming, and reduces thinking tokens. His "single coolest technique." Pair with ADRs.
3. Enforce the "build a tight, red-capable feedback loop first" gate before any debugging. No hypothesis until one command (already run) goes red on the exact symptom and is deterministic + fast + agent-runnable. This is the single biggest anti-flail upgrade for autonomous agents.
4. Steal the two-axis code-review harness: Standards (repo docs + Fowler smell baseline) and Spec (matches the originating issue), each in a parallel sub-agent, findings reported side-by-side and never cross-ranked. Maps cleanly onto the user's Sonnet-executor / Opus-reviewer seats and fresh-context review rule.
5. Add Evalite for eval-driven development on any AI SDK / tool-calling agent. Wrap models with wrapAISDKModel() for auto-trace+cache; start with faithfulness, answerCorrectness, and toolCallAccuracy scorers. Makes "which model / which edge cases break my agent" an automated, cost-aware test suite. <evalite.dev>
6. Enforce vertical-slice decomposition + HITL/AFK tagging for any multi-issue build, and sequence wide refactors as expand→migrate-in-batches→contract rather than one big diff. Only hand AFK-tagged, test-covered slices to unattended loops.
7. Install a git-guardrails PreToolUse hook (block push/reset --hard/clean/branch -D) — a ready-made, drop-in version of the user's "enforcement via hook, not prose" doctrine. skills/misc/git-guardrails-claude-code/.
8. Apply writing-great-skills to the user's own .claude collection. Audit for the six failure modes (esp. sediment, no-op, negation → prompt-the-positive), introduce leading words, and push reference behind context pointers. Directly improves an already-large personal skill library.