devflow-kit 1.8.3 → 2.0.1

package/plugins/devflow-implement/commands/implement.md

@@ -1,430 +0,0 @@
----
-description: Execute a single task through the complete lifecycle - orchestrates exploration, planning, implementation, and simplification with parallel agents
----
-
-# Implement Command
-
-Orchestrate a single task from exploration through implementation by spawning specialized agents. The orchestrator only spawns agents and passes context - all work is done by agents.
-
-## Usage
-
-```
-/implement <task description>
-/implement #42  (GitHub issue number)
-/implement      (use conversation context)
-```
-
-## Input
-
-`$ARGUMENTS` contains whatever follows `/implement`:
-- Task description: "implement JWT auth"
-- GitHub issue: "#42"
-- Empty: use conversation context
-
-## Phases
-
-### Phase 1: Setup
-
-Record the current branch name as `BASE_BRANCH` - this will be the PR target.
-
-Spawn Git agent to set up task environment. The Git agent derives the branch name automatically from the issue or task description:
-
-```
-Task(subagent_type="Git"):
-"OPERATION: setup-task
-BASE_BRANCH: {current branch name}
-ISSUE_INPUT: {issue number if $ARGUMENTS starts with #, otherwise omit}
-TASK_DESCRIPTION: {task description from $ARGUMENTS if not an issue number, otherwise omit}
-Derive branch name from issue or description, create feature branch, and fetch issue if specified.
-Return the branch setup summary."
-```
-
-**Capture from Git agent output** (used throughout flow):
-- `TASK_ID`: The branch name created by Git agent (use as TASK_ID for rest of flow)
-- `BASE_BRANCH`: Branch this feature was created from (for PR target)
-- `ISSUE_NUMBER`: GitHub issue number (if provided)
-- `ISSUE_CONTENT`: Full issue body including description (if provided)
-- `ACCEPTANCE_CRITERIA`: Extracted acceptance criteria from issue (if provided)
-
-### Phase 2: Orient
-
-Spawn Skimmer agent for codebase overview:
-
-```
-Task(subagent_type="Skimmer"):
-"Orient in codebase for: {task description}
-Run rskim on source directories (NOT repo root) to identify relevant files, functions, integration points"
-```
-
-### Phase 3: Explore (Parallel)
-
-Spawn 4 Explore agents **in a single message**, each with Skimmer context:
-
-| Focus | Thoroughness | Find |
-|-------|-------------|------|
-| Architecture | medium | Similar implementations, patterns, module structure |
-| Integration | medium | Entry points, services, database models, configuration |
-| Reusable code | medium | Utilities, helpers, validation patterns, error handling |
-| Edge cases | quick | Error scenarios, race conditions, permission failures |
-
-Track success/failure of each explorer for synthesis context.
-
-### Phase 4: Synthesize Exploration
-
-**WAIT** for Phase 3 to complete.
-
-**CRITICAL**: Do NOT synthesize outputs yourself in the main session.
-You MUST spawn the Synthesizer agent - "spawn Synthesizer" means delegate to the agent, not do the work yourself.
-
-```
-Task(subagent_type="Synthesizer"):
-"Synthesize EXPLORATION outputs for: {task}
-Mode: exploration
-Explorer outputs: {all 4 outputs}
-Failed explorations: {any failures}
-Combine into: patterns, integration points, reusable code, edge cases"
-```
-
-### Phase 5: Plan (Parallel)
-
-Spawn 3 Plan agents **in a single message**, each with exploration synthesis:
-
-| Focus | Output |
-|-------|--------|
-| Implementation steps | Ordered steps with files and dependencies |
-| Testing strategy | Unit tests, integration tests, edge case tests |
-| Execution strategy | SINGLE_CODER vs SEQUENTIAL_CODERS vs PARALLEL_CODERS decision |
-
-**Execution Strategy planner analyzes 3 axes:**
-
-| Axis | Signals | Decision Impact |
-|------|---------|-----------------|
-| **Artifact Independence** | Shared contracts? Integration points? | If coupled → SINGLE_CODER |
-| **Context Capacity** | File count, module breadth, pattern complexity | HIGH/CRITICAL → SEQUENTIAL_CODERS |
-| **Domain Specialization** | Tech stack detected (backend, frontend, tests) | Determines DOMAIN hints for Coders |
-
-**Context Risk Levels:**
-- **LOW**: <10 files, single module → SINGLE_CODER
-- **MEDIUM**: 10-20 files, 2-3 modules → Consider SEQUENTIAL_CODERS
-- **HIGH**: 20-30 files, multiple modules → SEQUENTIAL_CODERS (2-3 phases)
-- **CRITICAL**: >30 files, cross-cutting concerns → SEQUENTIAL_CODERS (more phases)
-
-### Phase 6: Synthesize Planning
-
-**WAIT** for Phase 5 to complete.
-
-**CRITICAL**: Do NOT synthesize outputs yourself in the main session.
-You MUST spawn the Synthesizer agent - "spawn Synthesizer" means delegate to the agent, not do the work yourself.
-
-```
-Task(subagent_type="Synthesizer"):
-"Synthesize PLANNING outputs for: {task}
-Mode: planning
-Planner outputs: {all 3 outputs}
-Combine into: execution plan with strategy decision (SINGLE_CODER | SEQUENTIAL_CODERS | PARALLEL_CODERS)"
-```
-
-**Synthesizer returns:**
-- Execution strategy type and reasoning
-- Context risk level
-- Subtask breakdown with DOMAIN hints (if not SINGLE_CODER)
-- Implementation plan with dependencies
-
-### Phase 7: Implement
-
-Based on Phase 6 synthesis, use the three-strategy framework:
-
-**Strategy Selection** (from Execution Strategy planner):
-
-| Strategy | When | Frequency |
-|----------|------|-----------|
-| **SINGLE_CODER** | Default. Coherent A→Z implementation | ~80% |
-| **SEQUENTIAL_CODERS** | Context overflow risk, layered dependencies | ~15% |
-| **PARALLEL_CODERS** | True artifact independence (rare) | ~5% |
-
----
-
-**SINGLE_CODER** (default):
-
-```
-Task(subagent_type="Coder"):
-"TASK_ID: {task-id}
-TASK_DESCRIPTION: {description}
-BASE_BRANCH: {base branch}
-EXECUTION_PLAN: {full plan from synthesis}
-PATTERNS: {patterns from exploration}
-CREATE_PR: true
-DOMAIN: {detected domain or 'fullstack'}"
-```
-
----
-
-**SEQUENTIAL_CODERS** (for HIGH/CRITICAL context risk):
-
-Spawn Coders one at a time, passing handoff summaries between phases:
-
-**Phase 1 Coder:**
-```
-Task(subagent_type="Coder"):
-"TASK_ID: {task-id}
-TASK_DESCRIPTION: {phase 1 description}
-BASE_BRANCH: {base branch}
-EXECUTION_PLAN: {phase 1 steps}
-PATTERNS: {patterns from exploration}
-CREATE_PR: false
-DOMAIN: {phase 1 domain, e.g., 'backend'}
-HANDOFF_REQUIRED: true"
-```
-
-**Phase 2+ Coders** (after prior phase completes):
-```
-Task(subagent_type="Coder"):
-"TASK_ID: {task-id}
-TASK_DESCRIPTION: {phase N description}
-BASE_BRANCH: {base branch}
-EXECUTION_PLAN: {phase N steps}
-PATTERNS: {patterns from exploration}
-CREATE_PR: {true if last phase, false otherwise}
-DOMAIN: {phase N domain, e.g., 'frontend'}
-PRIOR_PHASE_SUMMARY: {summary from previous Coder}
-FILES_FROM_PRIOR_PHASE: {list of files created}
-HANDOFF_REQUIRED: {true if not last phase}"
-```
-
-**Handoff Protocol**: Each sequential Coder receives the prior Coder's implementation summary via PRIOR_PHASE_SUMMARY and FILES_FROM_PRIOR_PHASE. The Coder's built-in branch orientation step handles git log scanning, file reading, and pattern discovery automatically.
-
----
-
-**PARALLEL_CODERS** (rare - truly independent artifacts):
-
-Spawn multiple Coders **in a single message**, each with independent subtask:
-
-```
-Task(subagent_type="Coder"):  # Coder 1
-"TASK_ID: {task-id}-part1
-TASK_DESCRIPTION: {independent subtask 1}
-BASE_BRANCH: {base branch}
-EXECUTION_PLAN: {subtask 1 steps}
-PATTERNS: {patterns}
-CREATE_PR: false
-DOMAIN: {subtask 1 domain}"
-
-Task(subagent_type="Coder"):  # Coder 2 (same message)
-"TASK_ID: {task-id}-part2
-TASK_DESCRIPTION: {independent subtask 2}
-BASE_BRANCH: {base branch}
-EXECUTION_PLAN: {subtask 2 steps}
-PATTERNS: {patterns}
-CREATE_PR: false
-DOMAIN: {subtask 2 domain}"
-```
-
-**Independence criteria** (all must be true for PARALLEL_CODERS):
-- No shared contracts or interfaces
-- No integration points between subtasks
-- Different files/modules with no imports between them
-- Each subtask is self-contained
-
-### Phase 8: Validate
-
-After Coder completes, spawn Validator to verify correctness:
-
-```
-Task(subagent_type="Validator", model="haiku"):
-"FILES_CHANGED: {list of files from Coder output}
-VALIDATION_SCOPE: full
-Run build, typecheck, lint, test. Report pass/fail with failure details."
-```
-
-**If FAIL:**
-1. Extract failure details from Validator output
-2. Increment `validation_retry_count`
-3. If `validation_retry_count <= 2`:
-   - Spawn Coder with fix context:
-   ```
-   Task(subagent_type="Coder"):
-   "TASK_ID: {task-id}
-   TASK_DESCRIPTION: Fix validation failures
-   OPERATION: validation-fix
-   VALIDATION_FAILURES: {parsed failures from Validator}
-   SCOPE: Fix only the listed failures, no other changes
-   CREATE_PR: false"
-   ```
-   - Loop back to Phase 8 (re-validate)
-4. If `validation_retry_count > 2`: Report failures to user and halt
-
-**If PASS:** Continue to Phase 9
-
-### Phase 9: Simplify
-
-After validation passes, spawn Simplifier to polish the code:
-
-```
-Task(subagent_type="Simplifier"):
-"Simplify recently implemented code
-Task: {task description}
-FILES_CHANGED: {list of files from Coder output}
-Focus on code modified by Coder, apply project standards, enhance clarity"
-```
-
-### Phase 10: Self-Review
-
-After Simplifier completes, spawn Scrutinizer as final quality gate:
-
-```
-Task(subagent_type="Scrutinizer"):
-"TASK_DESCRIPTION: {task description}
-FILES_CHANGED: {list of files from Coder output}
-Evaluate 9 pillars, fix P0/P1 issues, report status"
-```
-
-If Scrutinizer returns BLOCKED, report to user and halt.
-
-### Phase 11: Re-Validate (if Scrutinizer made changes)
-
-If Scrutinizer made code changes (status: FIXED), spawn Validator to verify:
-
-```
-Task(subagent_type="Validator", model="haiku"):
-"FILES_CHANGED: {files modified by Scrutinizer}
-VALIDATION_SCOPE: changed-only
-Verify Scrutinizer's fixes didn't break anything."
-```
-
-**If FAIL:** Report to user - Scrutinizer broke tests, needs manual intervention.
-
-**If PASS:** Continue to Phase 12
-
-### Phase 12: Alignment Check
-
-After Scrutinizer passes (and re-validation if needed), spawn Shepherd to validate alignment:
-
-```
-Task(subagent_type="Shepherd"):
-"ORIGINAL_REQUEST: {task description or issue content}
-EXECUTION_PLAN: {synthesized plan from Phase 6}
-FILES_CHANGED: {list of files from Coder output}
-ACCEPTANCE_CRITERIA: {extracted criteria if available}
-Validate alignment with request and plan. Report ALIGNED or MISALIGNED with details."
-```
-
-**If ALIGNED:** Continue to Phase 13
-
-**If MISALIGNED:**
-1. Extract misalignment details from Shepherd output
-2. Increment `alignment_fix_count`
-3. If `alignment_fix_count <= 2`:
-   - Spawn Coder to fix misalignments:
-   ```
-   Task(subagent_type="Coder"):
-   "TASK_ID: {task-id}
-   TASK_DESCRIPTION: Fix alignment issues
-   OPERATION: alignment-fix
-   MISALIGNMENTS: {structured misalignments from Shepherd}
-   SCOPE: Fix only the listed misalignments, no other changes
-   CREATE_PR: false"
-   ```
-   - Spawn Validator to verify fix didn't break tests:
-   ```
-   Task(subagent_type="Validator", model="haiku"):
-   "FILES_CHANGED: {files modified by fix Coder}
-   VALIDATION_SCOPE: changed-only"
-   ```
-   - If Validator FAIL: Report to user
-   - If Validator PASS: Loop back to Phase 12 (re-check alignment)
-4. If `alignment_fix_count > 2`: Report misalignments to user for decision
-
-### Phase 13: Create PR
-
-**For SEQUENTIAL_CODERS or PARALLEL_CODERS**: The last sequential Coder (with CREATE_PR: true) handles PR creation. For parallel coders, create unified PR using `git-workflow` skill patterns. Push branch and run `gh pr create` with comprehensive description, targeting `BASE_BRANCH`.
-
-**For SINGLE_CODER**: PR is created by the Coder agent (CREATE_PR: true).
-
-### Phase 14: Report
-
-Display completion summary with phase status, PR info, and next steps.
-
-### Phase 15: Record Decisions (if any)
-
-If the Coder's report includes Key Decisions with architectural significance:
-1. Read `~/.claude/skills/knowledge-persistence/SKILL.md` and follow its extraction procedure to record decisions to `.memory/knowledge/decisions.md`
-2. Source field: `/implement {TASK_ID}`
-3. Skip entirely if no architectural decisions were made
-
-## Architecture
-
-```
-/implement (orchestrator - spawns agents only)
-│
-├─ Phase 1: Setup
-│  └─ Git agent (operation: setup-task) - creates feature branch, fetches issue
-│
-├─ Phase 2: Orient
-│  └─ Skimmer agent (codebase overview via skim)
-│
-├─ Phase 3: Explore (PARALLEL, with Skimmer context)
-│  ├─ Explore: Architecture
-│  ├─ Explore: Integration
-│  ├─ Explore: Reusable code
-│  └─ Explore: Edge cases
-│
-├─ Phase 4: Synthesize Exploration
-│  └─ Synthesizer agent (mode: exploration)
-│
-├─ Phase 5: Plan (PARALLEL)
-│  ├─ Plan: Implementation steps
-│  ├─ Plan: Testing strategy
-│  └─ Plan: Execution strategy (3-strategy decision)
-│
-├─ Phase 6: Synthesize Planning
-│  └─ Synthesizer agent (mode: planning) → returns strategy + DOMAIN hints
-│
-├─ Phase 7: Implement (3-strategy framework)
-│  ├─ SINGLE_CODER (80%): One Coder, full plan, CREATE_PR: true
-│  ├─ SEQUENTIAL_CODERS (15%): N Coders with handoff summaries
-│  └─ PARALLEL_CODERS (5%): N Coders in single message (rare)
-│
-├─ Phase 8: Validate
-│  └─ Validator agent (build, typecheck, lint, test)
-│  └─ If FAIL: Coder fix loop (max 2 retries) → re-validate
-│
-├─ Phase 9: Simplify
-│  └─ Simplifier agent (refines code clarity and consistency)
-│
-├─ Phase 10: Self-Review
-│  └─ Scrutinizer agent (final quality gate, fixes P0/P1)
-│
-├─ Phase 11: Re-Validate (if Scrutinizer made changes)
-│  └─ Validator agent (verify Scrutinizer fixes)
-│
-├─ Phase 12: Alignment Check
-│  └─ Shepherd agent (validates alignment - reports only, no fixes)
-│  └─ If MISALIGNED: Coder fix loop (max 2 iterations) → Validator → re-check
-│
-├─ Phase 13: Create PR (if needed)
-│  └─ SINGLE_CODER: handled by Coder
-│  └─ SEQUENTIAL: handled by last Coder
-│  └─ PARALLEL: orchestrator creates unified PR
-│
-├─ Phase 14: Display agent outputs
-│
-└─ Phase 15: Record Decisions (inline, if any)
-```
-
-## Principles
-
-1. **Orchestration only** - Command spawns agents, never does work itself
-2. **Coherence-first** - Single Coder produces more consistent code (default ~80% of tasks)
-3. **Parallel exploration** - Explore and plan phases run in parallel; sequential phases wait
-4. **Agent ownership** - Each agent owns its output completely
-5. **Clean handoffs** - Each phase passes structured data to next; sequential Coders pass implementation summaries
-6. **Honest reporting** - Display agent outputs directly
-7. **Simplification pass** - Code refined for clarity before PR
-8. **Strict delegation** - Never perform agent work in main session. "Spawn X" means call Task tool with X, not do X's work yourself
-9. **Validator owns validation** - Never run `npm test`, `npm run build`, or similar in main session; always delegate to Validator agent
-10. **Coder owns fixes** - Never implement fixes in main session; spawn Coder for validation failures and alignment fixes
-11. **Loop limits** - Max 2 validation retries, max 2 alignment fix iterations before escalating to user
-
-## Error Handling
-
-If any agent fails, report the phase, agent type, and error. Offer options: retry phase, investigate systematically, or escalate to user.

package/plugins/devflow-implement/skills/agent-teams/SKILL.md

@@ -1,124 +0,0 @@
----
-name: agent-teams
-description: This skill should be used when the user asks to "create an agent team", "spawn teammates", "set up debate protocol", "coordinate agents", or discusses peer-to-peer agent collaboration, consensus formation, or team-based workflows. Provides patterns for team spawning, message passing, adversarial debate, and quality gates driven by multi-agent consensus.
-user-invocable: false
-allowed-tools: Read, Grep, Glob
----
-
-# Agent Teams Patterns
-
-Patterns for collaborative multi-agent workflows using Claude Code's Agent Teams feature. Teams enable peer-to-peer communication between agents, replacing one-way subagent reporting with adversarial debate and consensus.
-
-## Iron Law
-
-> **TEAMMATES CHALLENGE EACH OTHER**
->
-> Every finding must survive peer scrutiny. No unchallenged claims reach the final
-> report. A single agent's opinion is a hypothesis; consensus from debate is a finding.
-
----
-
-## When This Activates
-
-- Creating agent teams for review, implementation, or debugging
-- Spawning teammates with distinct perspectives
-- Coordinating multi-agent debate rounds
-- Forming consensus from conflicting findings
-
-## Core Patterns
-
-### Team Spawning
-
-Size team to task complexity. Assign distinct, non-overlapping perspectives.
-
-| Task Complexity | Team Size | Rationale |
-|----------------|-----------|-----------|
-| Simple review | 2-3 | Security + architecture sufficient |
-| Full review | 4-5 | Core perspectives covered |
-| Debug investigation | 3-5 | One per hypothesis |
-| Implementation | 2-4 | Domain-separated work units |
-| Specification | 3-4 | Debate requirements before user gates |
-| Resolution | 2-4 | Cross-validate fixes across batches |
-
-**Model guidance**: Explorers/Reviewers inherit parent model. Validators use `model: haiku`.
-
-### Detection and Fallback
-
-Attempt `TeamCreate`. If it fails or the tool is unavailable, fall back to parallel subagents:
-
-```
-try TeamCreate → success → proceed with team workflow
-                → failure → fall back to parallel Task() calls
-```
-
-Always document which mode was used in the final report.
-
-### Task List Coordination
-
-Use `TaskCreate` to give each teammate a trackable work unit. Lead checks `TaskList` for structured progress visibility beyond ad-hoc messages:
-
-```
-1. Lead creates tasks for each teammate's work unit
-2. Teammates claim tasks via TaskUpdate (owner: self)
-3. Teammates mark tasks completed when done
-4. Lead checks TaskList before proceeding to next phase
-```
-
-### Challenge Protocol
-
-1. **Initial work**: Each teammate completes independent analysis
-2. **Exchange**: Lead broadcasts "Share findings and challenge others"
-3. **Direct debate**: Teammates message each other with evidence
-4. **Resolution**: Contradictions resolved through 1-2 exchanges
-5. **Escalation**: Unresolved after 2 exchanges → report disagreement to lead
-
-### Consensus Formation
-
-| Agreement Level | Confidence | Report As |
-|----------------|------------|-----------|
-| Unanimous | HIGH | Confirmed finding |
-| Majority (>50%) | MEDIUM | Finding with noted dissent |
-| Split (50/50) | LOW | Disagreement with both perspectives |
-
-### Team Cleanup
-
-Lead MUST always handle cleanup:
-1. Ensure all teammates have completed or been shut down
-2. Call `TeamDelete` to release resources
-3. Verify no orphaned sessions remain
-4. **CRITICAL**: Confirm cleanup completed before creating next team
-
----
-
-## Limitations
-
-| Limitation | Impact | Guidance |
-|-----------|--------|----------|
-| One team per session | Cannot run two teams concurrently | Shut down and verify cleanup before creating next team |
-| No nested teams | Teammates cannot spawn sub-teams | Keep hierarchy flat; only lead creates teams |
-| No session resumption | Teammate state lost if interrupted | Start fresh; don't rely on teammate state persistence |
-| Shutdown can be slow | Cleanup may take several seconds | Wait for confirmation; don't race to create next team |
-| Task status may lag | Task list updates aren't instant | Use direct messages for time-sensitive coordination |
-| Permissions inherited | Teammates get lead's permissions at spawn | Cannot escalate permissions mid-session |
-
----
-
-## Anti-Patterns
-
-| Anti-Pattern | Correct Approach |
-|-------------|-----------------|
-| Overlapping perspectives | Assign distinct, non-overlapping focus areas |
-| Skipping debate round | Always require peer challenge before synthesis |
-| Unlimited debate | Cap at 2 exchanges per topic, then escalate |
-| Lead does analysis work | Lead coordinates only; teammates do analysis |
-| Ignoring minority opinion | Report dissent with evidence in final output |
-| Creating team before prior cleanup | Wait for TeamDelete confirmation, then create |
-| Messaging-only coordination | Use task list for structured progress tracking |
-
----
-
-## Extended References
-
-- `references/team-patterns.md` - Team structures for review, implement, debug, specify, resolve workflows
-- `references/communication.md` - Message protocols, broadcast patterns, debate formats
-- `references/cleanup.md` - Session management, orphan detection, resource cleanup

package/plugins/devflow-implement/skills/agent-teams/references/cleanup.md

@@ -1,104 +0,0 @@
-# Session Management and Cleanup
-
-## Team Lifecycle
-
-```
-1. Lead creates team
-2. Lead spawns teammates
-3. Teammates work independently
-4. Debate rounds (teammates message directly)
-5. Lead collects consensus
-6. Lead shuts down teammates
-7. Lead calls cleanup
-8. Lead verifies no orphans
-```
-
----
-
-## Cleanup Rules
-
-### Lead Responsibilities
-
-1. **Always call cleanup** - Even if team work was interrupted or errored
-2. **Shut down teammates first** - Before calling cleanup
-3. **Verify completion** - Check that no orphaned sessions remain
-
-### Error Handling
-
-If a teammate errors or hangs:
-1. Send shutdown message to the teammate
-2. Wait briefly for graceful shutdown
-3. Proceed with cleanup for remaining team
-4. Report the failed teammate in final output
-
-### Orphan Detection
-
-After cleanup, verify:
-- No tmux sessions from the team remain (split-pane mode)
-- No background processes from teammates
-- Team config at `~/.claude/teams/{team-name}/` is cleaned up
-
----
-
-## Known Limitations
-
-| Limitation | Mitigation |
-|-----------|------------|
-| No session resumption for teammates | Start fresh; don't rely on teammate state persistence |
-| One team per session | Queue team work sequentially if needed |
-| Task status may lag | Use direct messages for time-sensitive coordination |
-| No nested teams | Teammates cannot spawn sub-teams; keep hierarchy flat |
-| Split-pane requires tmux/iTerm2 | Fall back to in-process mode if unavailable |
-
----
-
-## Cost Management
-
-### Token Optimization
-
-| Strategy | Savings |
-|----------|---------|
-| Use haiku for validation teammates | ~70% per validation agent |
-| Limit debate to 2 rounds | Prevents runaway token usage |
-| Size teams to task (don't over-spawn) | Fewer agents = fewer tokens |
-| Shut down teammates promptly | No idle token consumption |
-
-### When NOT to Use Teams
-
-- Simple, single-focus tasks (use regular subagent)
-- Tasks requiring sequential dependency (no parallelism benefit)
-- Cost-sensitive operations where subagent is sufficient
-- Tasks where debate adds no value (e.g., formatting, simple fixes)
-
----
-
-## Sequential Team Transition Protocol
-
-Commands that create multiple teams (e.g., `/implement`, `/specify`) MUST follow this 4-step protocol between teams. Skipping steps causes silent failures due to the one-team-per-session constraint.
-
-```
-Step 1: SHUTDOWN — Send shutdown_request to each teammate by name
-  SendMessage(type: "shutdown_request", recipient: "{name}", content: "Phase complete")
-  Wait for each shutdown_response (approve: true)
-
-Step 2: DELETE — Remove team resources
-  TeamDelete
-
-Step 3: VERIFY — Confirm cleanup succeeded
-  If TeamDelete returned success → proceed
-  If TeamDelete failed → retry once after 5s
-  If retry fails → HALT and report to user:
-    "Team cleanup failed for {team-name}. Cannot create next team."
-
-Step 4: CREATE — Only now create the next team
-  TeamCreate(team_name: "{next-team-name}")
-```
-
-### Failure Modes
-
-| Failure | Action |
-|---------|--------|
-| Teammate ignores shutdown_request | Wait 30s, then proceed to TeamDelete (force cleanup) |
-| TeamDelete fails | Retry once after 5s delay |
-| TeamDelete retry fails | HALT execution, report to user |
-| TeamCreate fails after successful delete | Retry once; if fails, fall back to parallel Task() subagents |