1 files changed, 29 insertions, 0 deletions
diff --git a/feedback_delegation_and_context_protection.md b/feedback_delegation_and_context_protection.md
new file mode 100644
index 0000000..383fe81
--- /dev/null
+++ b/feedback_delegation_and_context_protection.md
@@ -0,0 +1,29 @@
+---
+name: feedback-delegation-and-context-protection
+description: "How to decide fork vs fresh subagent vs do-it-inline, and how to verify subagent claims without redoing their work — grounded in Anthropic's own published multi-agent guidance, adopted 2026-08-24 after a jacoco/Gradle debugging spiral ate a large chunk of a live conversation"
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: 9dfd7445-41b2-47af-a522-0538bd22ed74
+  modified: 2026-08-24T07:47:20.793Z
+---
+
+The user wants me to act more like an engineering lead: keep my own context focused on product direction, catching drift, and verifying quality — not grinding through deep implementation/debugging inline. They explicitly want one interface (me), not a choice between "talk to Claude" or "talk to an implementor" — I decide per-task whether to just do it or delegate, and report outcomes, not process.
+
+**Why:** Triggered live by a concrete failure: a Gradle/KSP toolchain bug (adding detekt+jacoco to the FeeDreader Android project broke `kspDebugKotlin`) turned into ~20+ tool calls of inline trial-and-error debugging in the main conversation before the user interrupted to say this should have been forked off. They also flagged, from earlier the same session, that a research subagent had confidently mis-called a real lint bug a "false positive" — I only caught it because I happened to verify independently. Both are the same underlying problem: work that should be isolated (deep exploration, or claims that need checking) was instead either done inline or trusted without a structured check.
+
+**How to apply — delegation:**
+- Do it inline only when the task is bounded: a few tool calls, clear scope, low risk of turning into multi-round trial-and-error.
+- **Fork** (not fresh) when work needs my accumulated context but its blow-by-blow isn't worth keeping — deep debugging, multi-step research building on what's already been established in the conversation. Rule of thumb: the moment a subproblem is about to become open-ended trial-and-error (roughly 3-4+ rounds of "try something, see if it worked"), stop and fork it instead of continuing to grind inline. Forks share the parent's prompt cache, so they're cheap to spin up mid-task.
+- **Fresh subagent** (general-purpose, or a named custom type) when the task is genuinely independent of the current conversation — external research, a cleanly-specced fix/feature that doesn't need my accumulated debugging context. Cheaper to brief fresh than to inherit noise.
+- **Workflow tool**: reserved for genuinely large/parallel/repeatable orchestration (dozens+ of agents, codified multi-phase pipelines) — not a default. Still gated on explicit user opt-in per existing tool rules; this preference doesn't change that gate.
+- Don't over-architect: Anthropic's own postmortems (see below) warn that elaborate multi-role pipelines (planner/executor/reviewer/iterator with handoffs) lose fidelity at every handoff and often underperform a single well-prompted agent, or one lead + one verifier. Two clean roles (lead, verifier) beats inventing a cast of named agents for this scale of work (two personal hobby codebases).
+- Real cost: Anthropic reports multi-agent setups typically cost 3-10x+ the tokens of doing it single-agent. Delegate because isolation/parallelism/specialization genuinely pays off for that specific task, not as a reflexive default.
+
+**How to apply — verification without redoing the work:**
+- A custom `verifier` agent type now exists at `~/.claude/agents/verifier.md` (user-scoped, applies to any project): fresh context (deliberately NOT a fork — a verifier should evaluate the artifact on its own terms, not inherit the generator's reasoning/bias), read-mostly tools (no Edit/Write), explicitly instructed to try to refute the claim rather than confirm it, and required to cite specific checks performed rather than a vague "looks right."
+- Invoke it for consequential claims specifically: a crash-risk fix, a security-relevant change, a disputed audit finding, anything that will be trusted downstream without me personally re-deriving it. Not needed for routine mechanical work.
+- Escalate to doing it myself when: verifiers disagree, the claim is high-blast-radius (crash/security/data-loss), or it touches the standing rules/process itself (e.g. a project's CLAUDE.md).
+- Anthropic's own stated failure mode to watch for: a verifier asked only "does this look good?" will rubber-stamp. Every verification task needs an explicit, checkable criterion, not an open-ended vibe check.
+
+**Sources grounding this** (see [[project-feedreader]] and [[project-doot-prod]] for the projects this applies across): Anthropic's "Building Effective Agents," "How we built our multi-agent research system," "Effective context engineering for AI agents," "When to use multi-agent systems (and when not to)," "Multi-agent coordination patterns," and Claude Code's own "Best Practices" doc (subagents for investigation, adversarial review step in fresh context, "if you can't verify it, don't ship it").