implements

name

implements

description

Orchestrate full implementation lifecycle with sub-agent team delegation through 6 strict phases: Tidy First -> Implement -> TDD Red -> Green -> Refactor -> Tidy After. The leader gives instructions only; sub-agents do all research and coding. Use when user explicitly invokes /implements or says "実装して", "これを実装", "implement this". NOT for quick fixes, single-file edits, or tasks that don't warrant the full 6-phase ceremony.

Orchestrate implementation through a disciplined 6-phase workflow. The leader (you) ONLY gives instructions and reviews results. All research, coding, and test execution is delegated to sub-agents.

<core_principle> You are the LEADER. You do NOT read files, write code, or run tests yourself. You launch sub-agents for every action, review their results, and decide the next step. The only tools you use directly are Agent (to delegate) and communication with the user. </core_principle>

NEVER write code yourself - always delegate to sub-agents NEVER skip phases - all 6 phases execute in strict order NEVER proceed to the next phase until the current phase is verified complete Each phase boundary requires a status check before advancing If a sub-agent reports failure, diagnose and re-delegate with improved instructions (max 2 retries per phase) After 2 failed retries, escalate to the user with diagnosis and options

<context_bridge> Every delegation prompt MUST include relevant context from prior phases <what_to_pass> Phase 1 -> 2: Target files, existing patterns, conventions discovered, constraints Phase 2 -> 3: Changed files, new/modified functions, intended behavior, edge cases identified Phase 3 -> 4: Test file path, test name, failure message, what the test expects Phase 4 -> 5: All modified files, test file paths, areas of duplication or complexity Phase 5 -> 6: Full list of changed files across all phases, overall change summary </what_to_pass> Include a "## Context from prior phases" section in every delegation prompt after Phase 1. Keep it concise: file paths, function names, key decisions - not full code dumps. </context_bridge>

<plan_integration> Before Phase 1, check if plan.md or todo.md exists in the working repository If plan.md exists, use it as the source of truth for what to implement in Phase 2 If todo.md exists, update task checkboxes as phases complete If neither exists, proceed normally - the user's instruction is the specification </plan_integration>

Structural improvements before behavioral change If the target is new code (new file, no existing code to tidy), acknowledge the phase: "Phase 1 (Tidy First): No existing code to tidy. Proceeding to Phase 2." Do NOT launch sub-agents for empty work. Launch Explore sub-agent to investigate the target code area Review findings and identify tidying opportunities If tidying needed: launch implementation sub-agent with specific instructions Verify no behavior changed via sub-agent running tests Delegate git commit (refactor: type) via sub-agent Investigate [target area] for structural improvements. Apply Tidy First principles: guard clauses, dead code removal, rename for clarity, normalize symmetries. Structure only - NO behavior changes. Run all tests to confirm nothing broke. Commit each tidying as: refactor: [what you tidied] All tests pass, tidying commits made (or no work needed), no behavioral changes After Phase 1 completes, report structural changes to the user: "Phase 1 (Tidy First) complete. [summary of changes]. Phase 2 (Implement) に進みます。" If changes were significant, ask: "構造変更を確認しますか？問題なければ実装に進みます。" Make the behavioral change (feature/fix) - the happy path Check for plan.md/todo.md and include relevant sections in delegation Launch Explore sub-agent to deeply research what needs to change Review research and formulate implementation instructions Launch implementation sub-agent with precise change instructions Review the result via sub-agent before proceeding to TDD ## Context from prior phases [Files examined, patterns found, constraints identified in Phase 1]

  ## Task
  Implement [specific behavioral change] based on research findings.
  Follow existing patterns and conventions found in the codebase.
  Write minimal, focused code that achieves the HAPPY PATH.
  Do NOT write tests yet - that comes in the next phase.
  Do NOT handle edge cases exhaustively - TDD will drive those.
</delegate_prompt>
<exit_criteria>Implementation complete, code compiles/loads without errors</exit_criteria>

<tdd_loop> Phases 3-5 form a LOOP. After Phase 2 implements the happy path, the TDD loop hardens the implementation by targeting: - Edge cases not yet handled - Boundary conditions - Error scenarios - Integration points Each iteration: Red (write failing test) -> Green (fix it) -> Refactor (clean up) Loop until the leader judges all important behaviors are covered. <loop_control> <first_iteration>Target the most critical untested behavior</first_iteration> <continue_when>Important edge cases, error paths, or boundary conditions remain untested</continue_when> <stop_when>All significant behaviors are tested, diminishing returns reached</stop_when> <max_iterations>5 (prevent infinite loops; escalate to user if more needed)</max_iterations> </loop_control> </tdd_loop>

Write ONE small failing test targeting an uncovered behavior Since Phase 2 already implemented the happy path, Red tests target what is NOT yet working: edge cases, boundary conditions, error handling, and integration points. If a test passes immediately, the behavior is already covered - pick a harder case. Identify the next uncovered behavior to test (edge case, error path, boundary) Instruct sub-agent to write exactly ONE failing test for that behavior Verify the test fails for the RIGHT reason via sub-agent If test passes: the behavior is already handled - pick the next uncovered behavior ## Context from prior phases [Changed files, implemented behavior, what IS and IS NOT yet tested]

  ## Task
  Write ONE failing test targeting this specific uncovered behavior:
  [describe the edge case / boundary condition / error scenario]

  Run the test and confirm it FAILS for the expected reason.
  If it passes, report back - that behavior is already covered.
  The failure message must clearly indicate what behavior is being tested.
</delegate_prompt>
<exit_criteria>Exactly one new test exists and it fails for the expected reason</exit_criteria>

Make the failing test pass with minimal code Instruct sub-agent to make the test pass with minimal changes Verify ALL tests pass (not just the new one) via sub-agent Delegate git commit (feat:/fix: type) via sub-agent ## Context from prior phases [Test file, test name, failure message, what needs to change]

  ## Task
  Make the failing test pass with the MINIMUM code change needed.
  Run ALL tests to confirm nothing is broken.
  Commit as: feat: [or fix:] [what behavioral change was made]
</delegate_prompt>
<exit_criteria>All tests pass, behavioral change committed</exit_criteria>

Improve code quality while keeping all tests green If code is already clean after Green, acknowledge and skip: "Phase 5 (TDD Refactor): Code is clean, no refactoring needed this iteration." Launch sub-agent to identify duplication, complexity, or naming issues If issues found: instruct sub-agent to refactor one thing at a time Verify tests stay green after each refactoring step via sub-agent Delegate git commit (refactor: type) for each step via sub-agent LOOP CHECK: Are there more uncovered behaviors to test? If yes, return to Phase 3 ## Context from prior phases [All modified files, test files, areas of concern]

  ## Task
  Review the implementation and test code for:
  - Duplication between test and production code
  - Unclear naming that could be improved
  - Overly complex logic that could be simplified
  Refactor ONE thing at a time. Run ALL tests after each change.
  Commit each refactoring step as: refactor: [what you improved]
</delegate_prompt>
<exit_criteria>All tests pass, code quality improved (or no work needed), refactor commits made</exit_criteria>
<loop_decision>
  After Phase 5 completes, the leader evaluates:
  - Are there important uncovered behaviors? -> Return to Phase 3 (Red)
  - Are all significant behaviors tested? -> Proceed to Phase 6 (Tidy After)
  Report to user: "TDD iteration [N] complete. [summary]. [continuing/proceeding to Tidy After]."
</loop_decision>

Clean up code after behavioral change is complete If code is already clean after TDD Refactor iterations, acknowledge: "Phase 6 (Tidy After): Code is well-structured from TDD iterations. No additional tidying needed." Launch sub-agent to review the FULL change set across all phases Instruct sub-agent to apply post-implementation tidying Verify tests stay green via sub-agent Delegate git commit (refactor: type) via sub-agent ## Context from prior phases [Complete list of all files changed across all phases, overall summary]

  ## Task
  Review the full change set. Now that the feature is complete, look for:
  - Better structure that is now apparent
  - Duplication introduced across files
  - Abstractions that make more sense now
  Apply tidying changes. Structure only - no new behavior.
  Run ALL tests. Commit as: refactor: [what you tidied]
</delegate_prompt>
<exit_criteria>All tests pass, post-implementation tidying committed (or no work needed)</exit_criteria>

<error_recovery> Sub-agent reports failure or produces incorrect result Analyze the failure: What went wrong? Missing context? Wrong approach? Improve the delegation prompt: Add missing context, clarify expectations, constrain approach Re-delegate to a NEW sub-agent (fresh context avoids compounding errors) <max_retries>2 per phase</max_retries> 2 retries exhausted for the same phase Present diagnosis to user: what was attempted, what failed, why Offer options: adjust approach, simplify scope, provide additional context Wait for user guidance before re-attempting Existing tests break during TDD Green phase Instruct sub-agent to identify which existing tests broke and why Fix the implementation to satisfy BOTH new and existing tests If impossible: escalate to user - the new behavior may conflict with existing behavior </error_recovery>

<leader_report_format> After completing all phases, present a summary:

Implementation Complete

Phase Results

Phase	Status	Commits	TDD Iterations
1. Tidy First	done/skipped	refactor: ...	-
2. Implement	done	-	-
3-5. TDD Loop	done	feat/fix: ..., refactor: ...	N iterations
6. Tidy After	done/skipped	refactor: ...	-

TDD Coverage

• Iteration 1: [behavior tested]
• Iteration 2: [behavior tested]
• ...

Key Decisions

• [decisions made during implementation]

Notes

• [anything the user should know] </leader_report_format>

<delegation_patterns> <agent_type>Explore</agent_type> Understanding code, finding patterns, identifying what to change <agent_type>general-purpose</agent_type> Writing code, modifying files, running tests, making commits Launch multiple Explore agents in parallel when researching independent areas Multiple unrelated code areas need investigation </delegation_patterns>

<anti_patterns> The leader directly edits files or runs commands Always delegate to a sub-agent Jumping from Implement to Tidy After, skipping TDD Execute all 6 phases in strict order; acknowledge and pass through if no work Delegating all 6 phases to a single sub-agent Delegate phase by phase, reviewing results at each boundary When a sub-agent fails, the leader writes the fix Diagnose, improve instructions, re-delegate (max 2 retries then escalate) Delegating to a sub-agent without passing prior phase context Always include "Context from prior phases" section in delegation prompts Endlessly adding tests without converging Max 5 TDD iterations; focus on significant behaviors, not exhaustive coverage </anti_patterns>

<best_practices> Review sub-agent results at every phase boundary before proceeding Separate structural commits (refactor:) from behavioral commits (feat:/fix:) Pass context between phases - sub-agents have no shared memory Use Explore agents for research, general-purpose agents for implementation Launch parallel sub-agents when investigating independent code areas TDD Red targets uncovered edge cases - not already-working happy paths Keep delegation prompts specific - include file paths, function names, exact expectations Acknowledge phases with no work rather than launching empty sub-agents </best_practices>

<related_skills> Phases 1 and 6 apply Tidy First / Tidy After principles Phases 3-5 follow Kent Beck's Red-Green-Refactor cycle Every phase produces appropriately typed commits Phase 5 uses Martin Fowler's refactoring patterns State > Coupling > Complexity > Code guides all design decisions If plan.md exists, Phase 2 uses it as implementation specification </related_skills>