workflow-analyze

name	workflow-analyze
description	Analyze issue and generate analysis.md with solution approaches. Use when starting a new task or feature to thoroughly analyze the problem and compare solution options.
disable-model-invocation	true

Issue Analysis Command

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

---

Outline

1. Parse User Input:

   • Extract task description from $ARGUMENTS
   • Generate task name (2-4 words, English, hyphen-separated)

2. Define Problem:

   • Identify current situation, problem to solve, and goals

3. Investigate Solutions:

   • Research 2-4 approaches
   • Analyze pros/cons of each approach
   • Evaluate based on coding principles

4. Final Selection:

   • Choose the most appropriate approach
   • Clarify rejection reasons

5. Generate Questions:

   • Select maximum 3 unclear items only
   • Use reasonable defaults + Assumptions for the rest

6. Write Documents (Dual Language):

   • Create docs/work/WORK-{task-name}/analysis.ko.md (Korean - for user reference)
   • Create docs/work/WORK-{task-name}/analysis.md (English - for agent consumption)
   • Use template structure below for both versions

---

Key Rules

🎭 Anti-Bias Rules (CRITICAL)

Core Principle: "Be honest. Don't hide what exists, don't invent what doesn't."

1. Analyze first, conclude later: Complete analysis of all approaches before making selection
2. Write what's true: If A has 5 pros and B has 1, write exactly that
3. Acknowledge trade-offs: When rejecting an approach, state what you're giving up
4. Use neutral language: Avoid "obviously", "simply", "clearly" — use "may", "could", "might"

📝 Documentation Language

CRITICAL: You must generate TWO versions of all documents:

1. Korean version (analysis.ko.md): For user reference - written in Korean
2. English version (analysis.md): For agent consumption - written in English

Both versions must contain identical structure and information, only the language differs.

🎯 Balanced Analysis Principles

1. Problem Definition: Include concrete scenarios rather than abstract descriptions
2. Solution Approach: Consider both user perspective and technical feasibility
3. Implementation Method: Keep core changes concise, specify new dependencies
4. Completion Criteria: Separate feature verification and technical implementation

✅ Must Do

• Conclusion first (Executive Summary)
• Include concrete scenarios (Problem Definition) - 1-4 cases depending on issue
• Explain user impact (Solution Approach) - How will it be used?
• Evaluate technical feasibility (Solution Approach) - Why is it suitable?
• Evaluate solutions based on coding principles
• Concise bullet points
• NEEDS CLARIFICATION maximum 3
• Use reasonable defaults

❌ Must Not Do

• Verbose explanations
• Duplicate content
• Only abstract problem definitions (without concrete examples)
• Excessive technical details (going into implementation level)
• Missing user perspective (talking only about technology)
• Solutions that conflict with coding principles
• Infinite questions
• Listing obvious things (e.g., React state, JSON schema)

📋 Clarification Priority

Priority: scope > security/privacy > user experience > technical details

🎯 Informed Guesses Principles

1. Make informed guesses: Use context, industry standards, and common patterns to fill gaps
2. Document assumptions: Record reasonable defaults in the Assumptions section
3. Limit clarifications: Maximum 3 [NEEDS CLARIFICATION] markers

---

Document Template

Files to create:

• docs/work/WORK-{task-name}/analysis.ko.md (Korean version)
• docs/work/WORK-{task-name}/analysis.md (English version)

# [Task Name] - Analysis Result

## 🎯 Conclusion (TL;DR)

**Selected Approach**: [Approach Name]
**Key Reason**: [Why this approach was chosen - 1-2 sentences]

---

## 📋 Problem Definition

**Concrete Scenarios** (as needed):

- [Case 1: What problem occurs in what situation]
- [Case 2: Another specific situation]

**Current Problem**: [What is inconvenient or impossible]
**Goal**: [What this task aims to achieve]

---

## 📦 Scope

**Included**:

- [Scope Item 1]
- [Scope Item 2]

**Excluded**:

- [What to explicitly exclude]

---

## 🔍 Solution Investigation

### Approach 1: [Name]

**Method**:

- [How to solve - including user impact and technical method]
- [If needed: How user experiences it]
- [If needed: How to implement technically]

**Pros**:

- [Why it's good - user/technical perspective]

**Cons**:

- [Why it could be problematic]

**Side Effects/Risks** (if any):

- [What negative consequences may occur even when successful]
- [Hidden costs, maintenance burden, technical debt introduced]

### Approach 2: [Name]

**Method**:

- [Solution method]

**Pros**:

- [...]

**Cons**:

- [...]

---

## ✅ Final Selection

**Adopted**: Approach N
**Selection Reason**:

- [Why this approach is most suitable]
- [Key benefits and trade-offs]

**Trade-offs Accepted** (if any):

- [Benefit from other approaches that won't be available]

**Rejected Approaches**:

- Approach X: [Rejection reason] — Would have provided: [lost benefit]

---

## 🛠️ Implementation Method

**Core Changes**:

- [Change Item 1]
- [Change Item 2]

**New Dependencies**: [None / Name]

---

## ⚙️ Key Considerations

- **Backward Compatibility**: [How to maintain existing behavior]
- **UI Placement**: [Where to place it]
- **Special Cases**: [Edge cases to consider]

---

## 🎯 Completion Criteria

**Feature Verification**:

- [ ] [Scenario 1 verification - actual use case test]
- [ ] [Scenario 2 verification]
- [ ] [Existing feature regression test]

**Technical Implementation**:

- [ ] [Core change implementation]
- [ ] [Required config/schema updates]
- [ ] [Unit test writing]

---

## ❓ Needs Confirmation

**Current Assumptions**:

- [Assumption 1]: [Default value]
- [Assumption 2]: [Default value]

**If Needed**:

- [Items needing additional confirmation - maximum 3]

---

## 🔍 Objectivity Self-Check

- [ ] Wrote what's true (no hiding, no inventing)
- [ ] Rejected approaches' lost benefits acknowledged
- [ ] Used neutral language ("may/could", not "will/obviously")

---

📚 Good/Bad Examples

Problem Definition Section

❌ Bad (Abstract only):

**Current Situation**: Problem occurs when using feature A
**Problem to Solve**: X is impossible
**Goal**: Make Y possible

✅ Good (Concrete + Abstract):

**Concrete Scenarios**:

- [Case 1: What problem occurs in specific situation]
- [Case 2: Another real situation]

**Current Problem**: [What is generally impossible]
**Goal**: [What becomes possible with this task]

---

Solution Investigation Section

❌ Bad (Technical only or User only):

### Approach 1: Use API X

**Method**: Call `function(param, flag: false)`
**Pros**: Native support
**Cons**: Complex testing

Or

### Approach 1: Add Option

**User Experience**: Click checkbox → behavior changes
**Pros**: Simple
**Cons**: Limited

✅ Good (Balanced explanation):

### Approach 1: [Approach Name]

**Method**:

- [How to solve - how user experiences it and how it works technically]
- If needed: Concrete usage flow (1→2→3)
- If needed: Core technical method

**Pros**:

- [Why it's good from user/technical perspective]

**Cons**:

- [What limitations or trade-offs exist]

---

Completion Criteria Section

❌ Bad (Technical implementation only):

- [ ] Add field X to type A
- [ ] Implement logic in module B
- [ ] Update config file

✅ Good (Feature verification + Technical implementation):

**Feature Verification**:

- [ ] [Scenario 1 verification - actual use case]
- [ ] [Verify behavior when option changes]
- [ ] [Existing feature regression test]

**Technical Implementation**:

- [ ] [Core type/interface changes]
- [ ] [Logic implementation]
- [ ] [Config/schema update]
- [ ] [UI implementation (if needed)]
- [ ] [Unit tests]

---

Execution

Now start the task according to the guidelines above.