mutual-agreement

name	mutual-agreement
version	1
description	Delegate work to a subagent with mutual review gates. Parent owns the plan and the commit. Subagent owns the implementation. Neither proceeds without the other's agreement.
argument-hint	Goal statement, file paths, and constraints for the change to delegate

Mutual Agreement

A delegation pattern where a parent agent and a subagent each own one phase and must agree before the other proceeds. Neither side does both planning and execution. The gates are explicit.

Handoff model

Parent ──[plan]──▶ Subagent
Parent ◀──[implementation]── Subagent
Parent ──[review + commit/push]──▶ repo

Phase 1: Parent → Subagent (plan only)

Parent formulates a complete, self-contained plan and hands it to a subagent via delegate_task. The plan includes:

• Goal — what the change achieves, in one sentence
• Background — why the change is needed, with enough context for the subagent to evaluate the plan independently (file paths, current behavior, constraints, design history if relevant)
• Proposed changes — numbered steps describing what to add/remove/modify, with specific line numbers, function names, or code snippets where possible
• Verification criteria — how to confirm the implementation is correct
• Constraints — what the subagent must NOT do (e.g. do not commit, do not modify unrelated files, do not change the interface unless the plan says so)

The plan must NOT include implementation code. It describes what to do, not the final diff. This is deliberate: the subagent's job is to translate the plan into code, which is a separate reviewable artifact.

The subagent prompt must include:

"Only implement if you agree with the plan. If you disagree with any part, explain why and propose alternatives. Do not commit or push."

Phase 2: Subagent → Parent (implementation IS the response)

The subagent reads the plan, evaluates it, and either:

• Agrees → implements the changes, writes them to disk. The subagent's response IS the implementation — not a proposal, not a description. The parent sees the diff when it reviews. Does NOT commit or push.
• Disagrees → returns an explanation of what's wrong with the plan and proposed alternatives. Does NOT implement.

The subagent's response is the implementation artifact the parent reviews. The parent must see: which files changed, what the diff looks like, and any deviations from the plan.

Phase 3: Parent reviews implementation

Parent reviews the subagent's output:

• Agrees → commits and pushes (or applies to the live system, or whatever the final action is). This is the parent's responsibility, never the subagent's.
• Disagrees → reverts or patches the implementation, then either commits a corrected version or re-dispatches the subagent with an updated plan.

The parent's commit message should credit the subagent's implementation while reflecting the parent's review (e.g. if the parent fixed something the subagent got wrong, the commit message notes it).

When to use this pattern

• Refactoring or restructuring existing code (the subagent needs to understand the full before proposing changes)
• Changes where the plan has meaningful alternatives the subagent might flag
• Any change to shared infrastructure, fleet config, or production systems
• When the user explicitly asks for mutual agreement

When NOT to use this pattern

• Simple, well-scoped changes (just do it directly)
• Pure research or analysis (no implementation to gate)
• When the user says "you do it" (they've delegated full authority)

Anti-patterns to avoid

• Parent includes implementation code in the plan. This defeats the purpose — the subagent becomes a copy-paste executor, not a reviewer. The plan should describe what, the subagent figures out how.
• Subagent commits or pushes. The subagent's job ends at writing files to disk. The commit is the parent's explicit agreement. If the parent doesn't commit, the implementation is rejected. Never include "commit+push" in the subagent's dispatch prompt — include "do not commit or push" instead.
• Parent rubber-stamps the implementation. If the parent doesn't actually review the diff, the agreement gate is theater. Read the changes. Verify the verification criteria from the plan.
• Subagent implements despite disagreeing. If the plan is wrong, say so. Don't implement something you think is incorrect just because the parent asked.