workflow-validate

通过原型或测试验证技术可行性。当您在正式投入实施前，对技术方案尚存疑虑时，此功能可助您厘清思路、消除顾虑。

SKILL.md

--- frontmatter

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)

text

$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/{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 Document:
- •Create docs/work/{name}/validation.md (Korean)
- •Include clear next steps recommendation

Key Rules

📝 Documentation Language

CRITICAL: All documents must be written in Korean.

🎯 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

📊 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.