Outline

Parse User Input:
- Extract task name from first word of $ARGUMENTS (e.g., "REFACTORING")
- Extract additional requirements from remaining text (e.g., "limit to 3 commits")
- If task name missing, ERROR: "Please provide task name: /workflow-plan TASK-NAME"
Check Prerequisites:
- Verify docs/work/{task-name}/analysis.md exists
- If not exists, use $ARGUMENTS as requirements source and proceed
Load Requirements:
- If analysis.md exists: Extract selected approach and completion criteria
- If not: Interpret user input as requirements (description, URL, file path, etc.)
Identify Impact Scope:
- List approximate classes/modules (not specific file names)
Decompose Commits (Vertical Slicing):
- Each commit should be independently deployable
- Consider additional requirements from user input (e.g., commit count limits, specific constraints)
- Forbid Horizontal Slicing: Don't separate types/logic/tests/UI into separate commits
- Vertical Slicing: Each commit includes types+logic+tests to provide complete functionality
- Order: Setup → Core → Integration → Polish
- Specify verification method and "independently deployable" status for each commit
- Test Classification: Each commit must specify:
  - TDD: Logic with conditionals/calculations → Write test FIRST
  - TEST-AFTER: UI/Integration/E2E → Implement then test
  - NO-TEST: Config/docs/type-only → Skip tests
Review Principle Violations:
- Create Complexity Tracking table if coding principle violations are necessary
Write Document:
- Create docs/work/{name}/plan.md (Korean)

Key Rules

📝 Documentation Language

CRITICAL: All documents must be written in Korean.

✅ Must Do

Checklist-focused
Reference analysis.md only (no repetition)
Vertical Slicing: Each commit independently deployable
Reflect coding principles
Impact scope approximate only

❌ Must Not Do

Redefine problem (it's in analysis.md)
List specific file names
Verbose explanations

🎯 Vertical Slicing Principles (CRITICAL)

Each commit must satisfy:

Build Success: No compilation errors
Preserve Existing Features: Pass existing tests
Independently Testable: Can be tested with this commit alone
Meaningful Value: Provides real value to users/developers

❌ Horizontal Slicing Forbidden:

Separating types only → logic only → tests only → UI only (X)
This separation makes each commit functionally incomplete

✅ Vertical Slicing Example:

Commit 1: types + logic + tests + schema (usable with manual config)
Commit 2: UI integration (complete UX)

🧪 Test Classification Rules

TDD Required (write failing test first):

Business logic with conditionals
Calculations, validations, parsers
State mutations, data transformations

TEST-AFTER (implement then test):

UI components with visual output
External API/DB integrations

NO-TEST (skip):

Config files (JSON, YAML, env)
Documentation, pure types, renames

📐 Test Level Selection

Levels (lowest effective level first):

Level	When to Use
`UNIT`	Pure functions, business logic, calculations, validation
`INT`	DB queries, API endpoints, service-to-service
`COMP`	UI components (render, interaction, accessibility)
`E2E`	Critical user journeys only (auth, payment, core flow)

Decision Quick Reference:

Conditional logic? → UNIT
Database involved? → INT
UI component? → COMP
Critical user journey? → E2E (only if below criteria met)

Mixed Levels: Use UNIT + E2E when feature needs both (e.g., discount logic + checkout flow)

E2E Justification Required: E2E tests are easy to write but expensive to run/maintain. Only use E2E when ALL apply:

Cannot test at lower level: Flow crosses multiple services/pages that mocking defeats the purpose
Revenue/trust critical: Auth, payment, core conversion paths
Historical bugs: This flow has broken in production before
Failure is catastrophic: Regulatory, security, or business-critical

Anti-pattern: Writing E2E for scenarios adequately covered by UNIT + INT tests.

📊 Phase Structure

Phase 1: Setup
Phase 2: Foundational
Phase 3+: User Stories (we call them Core features)
Final Phase: Polish

→ We apply as Commit order

Document Template

File to create: docs/work/{task-name}/plan.md (Korean)

# [Task Name] - Implementation Plan

> **Analysis Result**: See `analysis.md`
> **Selected Approach**: [Approach N]

## 📁 Impact Scope (Approximate)

**Main Areas**: [StatusBarManager, ConfigManager, etc.]

---

## 📝 Commit Plan

### ✅ Commit 1: [Title]

**Goal**: [1 sentence - describe complete value provided by this commit]

**Test Requirement**: [TDD | TEST-AFTER | NO-TEST]
**Test Level**: [UNIT | INT | COMP | E2E | UNIT + E2E]

**Task Checklist**:

- [ ] [Specific task 1]
- [ ] [Specific task 2]
- [ ] Test ([LEVEL]): [Specific test case] (if TDD/TEST-AFTER)
- [ ] Build verification: [Build command]

**Verification Method**:

1. [Specific verification method]
2. [User scenario]

**Independently Deployable**: ✅ / ⚠️ [Reason]

---

### ⬜ Commit 2: [Title]

**Goal**: [1 sentence - describe complete value provided by this commit]

**Test Requirement**: [TDD | TEST-AFTER | NO-TEST]
**Test Level**: [UNIT | INT | COMP | E2E | UNIT + E2E]

**Task Checklist**:

- [ ] [Specific task 1]
- [ ] [Specific task 2]
- [ ] Test ([LEVEL]): [Specific test case] (if TDD/TEST-AFTER)
- [ ] Build verification: [Build command]

**Verification Method**:

1. [Specific verification method]
2. [User scenario]

**Independently Deployable**: ✅ / ⚠️ [Reason]

---

## ⚠️ Principle Violation Justification (Only if needed)

| Violation | Why Necessary                | Why Simple Alternative Rejected |
| --------- | ---------------------------- | ------------------------------- |
| Using any | VS Code API types incomplete | Cost to fix @types > benefit    |

---

## 📊 Progress

- [ ] Commit 1
- [ ] Commit 2

Execution

Now start the task according to the guidelines above.

workflow-plan

Issue Planning Command

User Input