implement

name: implement description: "TDD implementation (RED→GREEN→REFACTOR) → verify → review. Use when a plan is approved and ready for coding. Drives the full chain automatically."

Implement

Chain (controller)

After implementation completes, run /verify immediately — never ask "shall I verify?"

Flow

Analysis → TDD (RED→GREEN→REFACTOR) → /verify → /review → /wrap

Execution

1. Analysis

• Read the plan (PLAN.md, PRD, or conversation context)
• Identify affected modules and their test files
• Create a branch if working in a git repo

2. Detect Test Infrastructure

Before writing code, check what test tooling exists:

• Look for test config files (jest.config, pytest.ini, Cargo.toml [dev-dependencies], vitest.config, etc.)
• Look for existing test directories or test files
• If test infrastructure exists → proceed with TDD
• If no test infrastructure exists → ask the user: "테스트 프레임워크가 없는데, 셋업할까요 아니면 테스트 없이 구현할까요?"

3. TDD Cycle (when test infrastructure available)

• RED: Write a failing test that specifies the expected behavior
• GREEN: Write minimal code to make the test pass
• REFACTOR: Clean up while keeping tests green

Business rules (scope limits, filter conditions, data boundaries) are best specified as tests rather than documentation — tests are executable specifications that stay in sync with the code.

4. Implementation Without Tests (fallback)

When the user opts out of testing or the project nature doesn't support it:

• Implement the feature following the plan
• Add inline comments for non-obvious logic
• Manually verify the behavior works before proceeding

5. Auto Chain

After implementation: /verify → /review → /wrap (continuous, no user prompts between steps)

Rules

• Business rules should have tests when test infrastructure exists — tests are the source of truth
• If a rule can't be tested (e.g., GUI-only workflows), document it in DECISIONS.md
• On verify failure → fix and re-verify
• Complete the full chain without stopping for confirmation