/execute2 — Disciplined Subagent Dispatch (portable pattern)

What this skill does

When you invoke /execute2 <task description>, this skill walks you (the parent agent) through dispatching ONE subagent with the full alignment discipline that was validated end-to-end in a real project (one dispatch, 9 of 9 verification checks passed). The pattern is portable — it works for any task in any project, not tied to any one initiative or codebase.

Core idea: every dispatch is simultaneously the task AND a live test of the alignment substrate. When the subagent drifts, you (parent) repair the tool that let the drift through before re-dispatching — never lower the bar.

What you get: a subagent return you can independently verify with ls, grep, wc, or domain-specific runnable commands — not a self-assessed "done."

When to use

Use /execute2 when:

• You're a parent agent and the next step is delegating a discrete task to a subagent
• You want falsifiable verification of the subagent's work, not "looks good"
• The task has clear deliverable artifacts (files, schemas, specs) you can check with commands
• You're willing to spend 30–60 seconds on the parent verification step on return

Don't use /execute2 when:

• The task requires synchronous in-conversation interaction (the subagent runs in background)
• You can't define a falsifiable verification contract (then your task isn't ready to dispatch — refine it first)
• The work touches code or systems where an additional human review gate must precede execution (use a more constrained pattern like /governer or stop and ask the human)

The 7-step dispatch sequence

Walk through these in order. Print each step's heading as you complete it so the person you're working with can see the substrate firing.

---

Step 1 — Define the task in 1-3 sentences

Write the task you're dispatching as a clear, scoped statement. Not "improve X" — "produce a YAML schema covering A, B, C and verify against existing telemetry source D."

If you cannot state the task in ≤3 sentences, the task is too big — decompose first.

---

Step 2 — Identify the ascendant chain

What context must the subagent read before acting? List file paths the subagent should consume in order, parent-to-self.

Inside a large initiative with its own layered rules docs (example: a multi-phase internal initiative with a root intent doc, a rules index, and per-phase guides):

• L0 root intent → L1 grandparent initiative → L2 parent intent → L3 rules index → L4 guide/rules → L5 self charter

Outside an initiative — minimum viable chain:

• L0 project root context (CLAUDE.md, README, or top-level intent doc)
• L1 the immediate parent context (your current session intent or the task's domain doc)
• L2 self charter (a brief you write inline OR a doc you create for the subagent)

Write the chain as a numbered list with full file paths. The subagent will be required to confirm reading each level in its first output.

---

Step 3 — Draft the falsifiable verification contract (V1-V9 minimum)

Each Vn must be checkable with a runnable command (file exists, grep returns N+ hits, count matches expected, command exits 0). Avoid Vns that require human judgment.

Minimum-viable contract template — adapt per task:

V1 <output artifact 1> exists at <exact path>
V2 <output artifact 2> exists at <exact path> (if applicable)
V3 Spec/output covers <named element 1, 2, 3> — verify by grep on <pattern>
V4 <count check> — e.g., bundle has N items matching source data count
V5 At least <N> citations from existing artifacts (verify via grep)
V6 ASCENDANT_CHAIN_READ block populated in subagent's first output (verify via grep)
V7 Handoff contract complete with RECOVERABLE_DRAFTS field populated even on success
V8 SELF_HEAL_LOG block per low-confidence-self-heal pattern
V9 No code touched (if applicable) — verify via git diff or absence of file edits outside expected paths

Falsifiability test: if you cannot describe the runnable command for each Vn, it's not falsifiable — refine until you can.

---

Step 4 — Compose the dispatch prompt (self-contained packet)

The subagent has zero memory of your conversation. The prompt must be self-contained. Include in this exact order:

1. Subagent identity: "You are dispatched by for task "
2. STOP banner: "Read the full ascendant chain below before any action"
3. Ascendant chain list from Step 2 (full paths)
4. DO NOT list: explicit prohibitions (no code edits, no sibling reads, no parent-doc edits, no skill files, no self-evaluation)
5. Required first-output blocks: ASCENDANT_CHAIN_READ confirmation, charter understanding restatement
6. Charter from Step 1 (the task)
7. Deliverable paths: exact file paths the subagent must produce
8. Verification contract V1-V9 from Step 3 (so the subagent knows what they'll be measured against)
9. Handoff contract template: required return format (see below)
10. Why this matters: 2-3 sentences naming what this dispatch tests / why the discipline matters

Required handoff contract template (paste into prompt)

HANDOFF_CONTRACT:
  FROM:                 <subagent id>
  TO:                   <parent agent id>
  TASK:                 <one sentence grounded in charter>
  ASCENDANT_READ:       L0-L<N> YES
  INPUT_DOCS:           [list every source file read]
  OUTPUT_DOCS:          [every file written, every section appended]
  SELF_HEAL_LOG:        [INITIAL_CONFIDENCE → assumptions → resolutions → FINAL_CONFIDENCE → ITERATIONS]
  RECOVERABLE_DRAFTS:   [content of any partial work, even on success — preserves work if blocked]
  CONFIDENCE:           <%>
  CITATIONS:            [every fact source]
  UNKNOWN:              [what couldn't be verified — becomes follow-up open questions]
  COULD_BE_WRONG_BECAUSE: [explicit risks]
  APPEND_TARGET:        <where parent will record outcome>

Any empty field invalidates the return — subagent must halt and ask, not fabricate.

---

Step 5 — Dispatch in background

Use the Agent tool with:

• subagent_type: general-purpose (most flexible) — or a more specialized type if appropriate
• model: opus (or sonnet for lower-stakes / faster turns)
• run_in_background: true — always. A subagent you have to wait for silently is worse than one running in the background while you stay available; going silent to tail a foreground agent has been a repeated, corrected mistake when using this pattern, and the fix is simply: always background it.
• mode: "bypassPermissions" (a documented, explicit choice — not a default) — use this when the subagent needs to write to any path outside the current project's working directory (e.g., the user's own ~/.claude/ config or skills folder, a shared temp directory). Without it, background subagents are restricted to writes within the project tree even when the parent session itself runs with a broader permission mode — that broader mode does NOT flow into subagent dispatches automatically. Turning this on lets the subagent write anywhere the person could write by hand, so only turn it on when the task actually needs writes outside the project, and say so when you do.
• prompt: the full self-contained packet from Step 4
• description: a 3-5 word task summary

When to use bypassPermissions vs leaving unset:

• Subagent writes to the user's own home-directory config, a shared temp directory, or anywhere else outside the current project folder → mode: "bypassPermissions"
• Subagent writes only within the project root (e.g., editing code, adding migration files) → leave unset (inherits project permissions)

Print the dispatch decision in chat:

🚀 /execute2 dispatching: <task name> | model: <opus|sonnet> | bg: true | ETA: <estimate>

Stay available to the person you're working with while the subagent works — do NOT silently wait or go quiet while tailing its progress.

---

Step 6 — Independent V1-V9 verification on return (NEVER self-assessment)

When the subagent returns its handoff contract, you (parent) must run each Vn check yourself with a runnable command. Do not accept the subagent's self-claim.

Per the Anthropic Generator/Evaluator pattern, and the explicit principle that agents praise their own work — never self-evaluate:

• For "file exists" checks → ls -la <path> and read the output
• For "grep returns N+ hits" checks → grep -c '<pattern>' <file> and read the count
• For "count matches" checks → run the count, compare to expected
• For "block present" checks → grep for the block header in the subagent's return text

Print each Vn result as a table:

| V1 | <method>          | claim: <subagent>       | actual: <command output>     | ✅ PASS / ❌ FAIL |

If all PASS → subagent's work is verified, mark task complete in your tracking surface.

---

Step 7 — Tool repair if any Vn fails (parent self-enforcing loop)

If any Vn fails:

1. Diagnose what in the dispatch tool let the drift through. Was the charter ambiguous? Did the verification contract not specify what good looks like? Was the DO NOT list missing a constraint?
2. Repair the tool, not the subagent's output. Add the missing constraint to the charter template, the DO NOT list, the verification contract, or this /execute2 skill itself.
3. Re-dispatch with the repaired tool — never accept drifted output by lowering the bar.
4. Log the TOOL_REPAIR in your tracking surface (or in the parent doc §17 if inside an initiative):

TOOL_REPAIR:
  DRIFT_OBSERVED:   <one line — what the subagent did that violated contract>
  ROOT_CAUSE:       <which part of the tool was insufficient>
  REPAIR:           <what you changed in the tool>
  RE_DISPATCH:      YES | NO
  OUTCOME:          <result of re-dispatch if applicable>

This is the parent-agent self-enforcing loop. Every dispatch is a live test of the substrate — when it breaks, you fix it before using it again.

---

Anti-patterns (do NOT do)

• NEVER accept self-assessment: subagent saying "all checks pass" is not a check — re-run each Vn yourself.
• NEVER silently re-dispatch the same charter after a drift — that treats the symptom not the cause.
• NEVER lower the verification bar to make drifted output pass — the point is the tool caught the drift.
• NEVER let the parent layer skip this loop even if the subagent layer ran cleanly. The loop fires at every parent level recursively.
• NEVER dispatch without a falsifiable verification contract — without it, you can't tell if the work is right or just looks right.

Why this overhead is worth it

Validated in a real project (a real subagent dispatch test): one Opus subagent received a self-contained packet, read the full ascendant chain, followed all canonical rules, produced two falsifiable artifacts, returned with a complete handoff contract including RECOVERABLE_DRAFTS, and the parent agent independently verified V1-V9 with ls, grep, wc. 9/9 PASS. The substrate works. That was one run in one project — evidence that the method works, not proof that it always will; treat it the same way in your own project until you've run it enough times to trust it there too.

The pattern was extracted from internal process documentation for a large multi-agent initiative (a root "parent agent self-enforcing loop" rule and a canonical-rules index) and packaged here so any agent in any project can invoke it.

Relationship to other skills

• /governer — scoring + leverage routing. /execute2 complements /governer — /governer decides IF this is worth dispatching; /execute2 is HOW you dispatch with discipline.
• /governer2 — experimental scoring with forced workflow stages and oracle enrichment. Different scope from /execute2. Both can be used in the same task.
• /execute (v1) — session-persistent adversarial team. /execute2 is single-dispatch with verification, not a persistent team.
• /orchestrator — top-level coordination role. /execute2 is what an orchestrator uses for each individual delegation.
• /dispatch-seed — pipeline from intent alignment to dispatch. Use /dispatch-seed to get a seed approved; use /execute2 to dispatch the work that the seed describes.
• The "parent agent self-enforcing loop" rule (from a large internal multi-agent initiative) — the originating doc. /execute2 is the portable extraction.

Minimum-viable mode (for ad-hoc dispatch outside an initiative)

If you're using /execute2 outside an initiative with canonical rules, the ascendant chain shrinks to:

• L0: project root context (CLAUDE.md or top-level intent)
• L1: your session's task intent (write inline as the dispatch prompt's "Charter" section)
• L2: self charter (the brief)

Verification contract still required. RECOVERABLE_DRAFTS still required. Parent verification still required. The discipline is the value — don't skip it because the project is small.

Origin

Created as the portable extraction of a dispatch discipline developed inside a large internal multi-agent initiative, packaged as a standalone skill so the pattern could be tested independently of that initiative.

Validation: one real dispatch in a real project passed all 9 of 9 verification checks (see above) — the exemplar of what a verified subagent return looks like when the method is followed.