| name | workflow-validate |
| description | Validate technical feasibility with prototypes or tests. Use when uncertain about technical approach before committing to implementation. |
| disable-model-invocation | true |
Technical Validation Command
User Input (Optional)
$ARGUMENTS
Optional input:
- Empty: Auto-determine validation method based on analysis.md
- Provided: Must consider user instructions (e.g., specific validation method, additional requirements)
Outline
-
Check Prerequisites:
- Verify
docs/work/WORK-{name}/analysis.md exists
- If not, ERROR: "Run /workflow-analyze first"
-
Load Analysis Document:
- Extract selected approach from analysis.md
- Identify key technical assumptions and risks
-
Determine Validation Method:
- Choose appropriate validation approach based on context:
- Prototype implementation
- UI/UX verification (Playwright MCP)
- TDD approach
- Library/API exploration
- Technical documentation research
- User verification delegation
-
Execute Validation:
- Perform selected validation method
- Create prototype code in
__prototype__/{feature-name}/ if needed
- Collect results and evidence
-
Assess Results:
- Determine status: โ
Success / โ ๏ธ Partial Success / โ Failure
- Document findings and constraints
-
Write Documents (Dual Language):
- Create
docs/work/WORK-{name}/validation.ko.md (Korean - for user reference)
- Create
docs/work/WORK-{name}/validation.md (English - for agent consumption)
- Include clear next steps recommendation
Key Rules
๐ Documentation Language
CRITICAL: You must generate TWO versions of all documents:
- Korean version (
validation.ko.md): For user reference - written in Korean
- English version (
validation.md): For agent consumption - written in English
Both versions must contain identical structure and information, only the language differs.
๐ฏ Validation Principles
- Focus on Core Risks: Validate only critical technical uncertainties
- Practical Approach: Sufficient confidence over perfect validation
- Clear Judgement: Explicit success/failure with next steps
โ
Must Do
- Validate only what's uncertain
- Create minimal working code (if prototype)
- Document all findings clearly
- Provide actionable next steps
- Reference analysis.md for context
- Store prototype in
__prototype__/ directory
โ Must Not Do
- Full implementation (save for execute phase)
- Validate obvious/known facts
- Repeat analysis.md content
- Give ambiguous conclusions ("maybe works")
- Over-engineer the validation
๐ฌ Validation Methods Selection
Choose based on uncertainty type:
| Uncertainty Type | Validation Method | Output |
|---|
| Core logic feasibility | Prototype implementation | Working code + results |
| UI/UX changes | Playwright verification | Screenshots + test results |
| Complex algorithms | TDD approach | Test code + edge cases |
| External dependencies | Library exploration | Sample code + compatibility |
| Standards/patterns | Documentation research | Summary + recommendations |
| Environment-specific | User delegation | Test guide + checklist |
๐ Prototype Code Management
Location: __prototype__/{feature-name}/
How to create:
- Validate directly in actual codebase (modifying files is OK)
- After validation, extract core logic to
__prototype__/
- Don't commit actual code changes (revert or leave as-is)
Purpose:
- Reference for plan/execute phases
- Archive of validated core logic
- Proof of technical feasibility
Lifecycle:
- Created during validate
- Referenced in execute
- User manages cleanup
Document Template
Files to create:
docs/work/WORK-{task-name}/validation.ko.md (Korean version)
docs/work/WORK-{task-name}/validation.md (English version)
Template A: AI-Completed Validation
# ๊ธฐ์ ๊ฒ์ฆ ๋ณด๊ณ ์
## ๐ฏ ๊ฒ์ฆ ๋ชฉํ
**ํต์ฌ ์ง๋ฌธ**: [๊ฒ์ฆํ๋ ค๋ ๊ธฐ์ ์ ๋ถํ์ค์ฑ]
**๊ฒ์ฆ ๋ฒ์**: [๊ฒ์ฆ ๋์ ๋ฐ ์ ์ธ ์ฌํญ]
---
## ๐ฌ ๊ฒ์ฆ ๋ฐฉ๋ฒ
**์ ํํ ๋ฐฉ๋ฒ**: [ํ๋กํ ํ์
/ํ
์คํธ/์กฐ์ฌ ๋ฑ]
**๊ฒ์ฆ ํ๊ฒฝ**: [์ฌ์ฉํ ๋๊ตฌ ๋ฐ ์ค์ ]
---
## ๐ ๊ฒ์ฆ ๊ฒฐ๊ณผ
**์ํ**: โ
์ฑ๊ณต / โ ๏ธ ๋ถ๋ถ ์ฑ๊ณต / โ ์คํจ
**ํต์ฌ ๋ฐ๊ฒฌ์ฌํญ**:
- [์ฃผ์ ๋ฐ๊ฒฌ 1]
- [์ฃผ์ ๋ฐ๊ฒฌ 2]
---
## ๐ก ๋ฐ๊ฒฌ๋ ์ฌํญ
### ๊ธ์ ์ ์์
- [์์๋๋ก ์๋ํ๋ ๋ถ๋ถ]
- [์ถ๊ฐ๋ก ๋ฐ๊ฒฌํ ์ฅ์ ]
### ์ ์ฝ์ฌํญ/๋ฆฌ์คํฌ
- [๊ธฐ์ ์ ์ ์ฝ]
- [์ฑ๋ฅ ์ด์]
- [ํธํ์ฑ ๋ฌธ์ ]
---
## ๐ ๏ธ ํ๋กํ ํ์
์ฝ๋ (if created)
**์์น**: `__prototype__/{feature-name}/`
**ํต์ฌ ๊ตฌํ**:
- [๊ตฌํํ ํต์ฌ ๋ก์ง ์ค๋ช
]
- [ํ
์คํธ ๋ฐฉ๋ฒ ๋ฐ ๊ฒฐ๊ณผ]
**์ฐธ๊ณ ์ฌํญ**:
- [execute ๋จ๊ณ์์ ์ฃผ์ํ ์ ]
- [๊ฐ์ ๊ฐ๋ฅํ ๋ถ๋ถ]
---
## โ
๊ถ์ฅ์ฌํญ
**๋ค์ ๋จ๊ณ**: `/workflow-plan` ์งํ / `/workflow-analyze` ์ฌ๊ฒํ
**๊ตฌํ์ ์ฃผ์์ฌํญ**:
- [์ฃผ์์ฌํญ 1]
- [์ฃผ์์ฌํญ 2]
**๋์ (ํ์์)**:
- [๋์ 1]: [์ฅ๋จ์ ]
- [๋์ 2]: [์ฅ๋จ์ ]
---
## ๐ ์ฐธ๊ณ ์๋ฃ
- [๊ด๋ จ ๋ฌธ์ ๋งํฌ]
- [์ฐธ๊ณ ํ ๋ผ์ด๋ธ๋ฌ๋ฆฌ ๋ฌธ์]
Template B: User Verification Request
# ๊ธฐ์ ๊ฒ์ฆ ๊ฐ์ด๋
## ๐ฏ ๊ฒ์ฆ ๋ฐฐ๊ฒฝ
**AI๊ฐ ์ง์ ๊ฒ์ฆํ ์ ์๋ ์ด์ **: [ํ๊ฒฝ/์ ๊ทผ/๋๋ฉ์ธ ์ ์ฝ]
**์ฌ์ฉ์ ๊ฒ์ฆ์ด ํ์ํ ๋ถ๋ถ**: [๊ตฌ์ฒด์ ๊ฒ์ฆ ๋์]
---
## โ
๊ฒ์ฆ ์ฒดํฌ๋ฆฌ์คํธ
### ํ์ ํ์ธ ์ฌํญ
- [ ] [ํ์ธ ํญ๋ชฉ 1]: [ํ์ธ ๋ฐฉ๋ฒ]
- [ ] [ํ์ธ ํญ๋ชฉ 2]: [ํ์ธ ๋ฐฉ๋ฒ]
- [ ] [ํ์ธ ํญ๋ชฉ 3]: [ํ์ธ ๋ฐฉ๋ฒ]
---
## ๐งช ํ
์คํธ ์๋๋ฆฌ์ค
### ์๋๋ฆฌ์ค 1: [์ ๋ชฉ]
**๋ชฉ์ **: [๋ฌด์์ ํ์ธํ๋ ค๋์ง]
**๋จ๊ณ**:
1. [๊ตฌ์ฒด์ ์คํ ๋จ๊ณ]
2. [๊ตฌ์ฒด์ ์คํ ๋จ๊ณ]
3. [๊ตฌ์ฒด์ ์คํ ๋จ๊ณ]
**์์ ๊ฒฐ๊ณผ**: [์ ์ ๋์์ ๊ธฐ๋ ๊ฒฐ๊ณผ]
**ํ์ธ ํฌ์ธํธ**:
- [๋ฌด์์ ๋ด์ผ ํ๋์ง]
- [์ด๋ค ๊ฐ์ ํ์ธํด์ผ ํ๋์ง]
### ์๋๋ฆฌ์ค 2: [์ ๋ชฉ]
[์๋๋ฆฌ์ค 1๊ณผ ๋์ผํ ๊ตฌ์กฐ]
---
## โ ํ์ธ ์ง๋ฌธ
1. **[๊ตฌ์ฒด์ ์ง๋ฌธ]**
- ๋ฐฐ๊ฒฝ: [์ ์ด๊ฒ์ด ์ค์ํ์ง]
- ํ๋จ ๊ธฐ์ค: [์ด๋ป๊ฒ ํ๋จํ ์ง]
2. **[๊ตฌ์ฒด์ ์ง๋ฌธ]**
- ๋ฐฐ๊ฒฝ: [์ ์ด๊ฒ์ด ์ค์ํ์ง]
- ํ๋จ ๊ธฐ์ค: [์ด๋ป๊ฒ ํ๋จํ ์ง]
---
## ๐ ๊ฒ์ฆ ์๋ฃ ํ
**๊ฒฐ๊ณผ ๊ณต์ ๋ฐฉ๋ฒ**:
- ๊ฐ ์ฒดํฌ๋ฆฌ์คํธ ํญ๋ชฉ๋ณ ํต๊ณผ/์คํจ ํ์
- ๋ฐ๊ฒฌ๋ ๋ฌธ์ ๋ ์ ์ฝ์ฌํญ ์ค๋ช
- ์คํฌ๋ฆฐ์ท์ด๋ ๋ก๊ทธ ์ฒจ๋ถ (ํ์์)
**๋ค์ ๋จ๊ณ**:
- ๊ฒ์ฆ ์ฑ๊ณต์: `/workflow-plan` ์งํ
- ๋ฌธ์ ๋ฐ๊ฒฌ์: ๋์ ๋
ผ์ ํ์
๐ Validation Status Guidelines
โ
Success Criteria
- All core technical assumptions validated
- No blocking issues found
- Clear path to implementation
- Next: Proceed to
/workflow-plan
โ ๏ธ Partial Success Criteria
- Main approach works with constraints
- Workarounds or alternatives available
- Trade-offs acceptable
- Next: Document constraints, get user confirmation
โ Failure Criteria
- Core approach not feasible
- Blocking issues without workarounds
- Fundamental assumptions invalid
- Next: Return to
/workflow-analyze for re-evaluation
๐ฏ Spike Principles
This validation follows Agile Spike methodology:
- Risk Reduction: Focus on highest risk items
- Just Enough: Minimal code for maximum learning
- Throwaway Code: Prototypes are for learning, not production
- Clear Outcome: Binary decision on feasibility
Execution
Now start the validation task according to the guidelines above.