Issue Analysis Command

User Input

text

$ARGUMENTS

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

Outline

•
Parse User Input:
- •Extract task description from $ARGUMENTS
- •Generate task name (2-4 words, English, hyphen-separated)
•
Define Problem:
- •Identify current situation, problem to solve, and goals
•
Investigate Solutions:
- •Research 2-4 approaches
- •Analyze pros/cons of each approach
- •Evaluate based on coding principles
•
Final Selection:
- •Choose the most appropriate approach
- •Clarify rejection reasons
•
Generate Questions:
- •Select maximum 3 unclear items only
- •Use reasonable defaults + Assumptions for the rest
•
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

📝 Documentation Language

CRITICAL: You must generate TWO versions of all documents:

•Korean version (analysis.ko.md): For user reference - written in Korean
•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

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

🎭 Anti-Bias Rules (CRITICAL)

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

•
Analyze First, Conclude Later
- •Complete ALL approach analysis BEFORE making any selection
•
Write What's True
- •If A has 5 pros and B has 1, write exactly that (no forced balance)
- •If side effects exist, state them; if none, say so (no hiding, no inventing)
- •When rejecting an approach, acknowledge what you're giving up
•
Neutral Language
- •Forbidden: "simply", "obviously", "clearly", "just", "merely"
- •Use: "may", "could", "potentially"

✅ 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

•Make informed guesses: Use context, industry standards, and common patterns to fill gaps
•Document assumptions: Record reasonable defaults in the Assumptions section
•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)

markdown

# [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]
- [List ALL genuine pros - don't artificially limit or inflate]

**Cons**:

- [Why it could be problematic]
- [List ALL genuine cons - don't hide any]

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

- [What negative consequences may occur even when successful]
- [Hidden costs, maintenance burden, technical debt introduced]
- [If none: "None identified" or omit section]

### Approach 2: [Name]

**Method**:

- [Solution method]

**Pros**:

- [List ALL genuine pros honestly]

**Cons**:

- [List ALL genuine cons honestly]

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

- [Be honest - if none exist, say so or omit]

---

## ✅ Final Selection

**Adopted**: Approach N

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

- [Benefit from other approaches that won't be available]
- [If none significant: "Minimal - selected approach is clearly superior for this case"]

**Known Risks** (if any):

- [What could go wrong even with successful implementation]
- [If none identified: state so honestly]

**Selection Reason**:

- [Why this approach is most suitable despite the above trade-offs]

**Rejected Approaches** (include what you're losing):

- Approach X: [Rejection reason] — Would have provided: [lost benefit]
- Approach Y: [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):

markdown

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

✅ Good (Concrete + Abstract):

markdown

**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):

markdown

### Approach 1: Use API X

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

markdown

### Approach 1: Add Option

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

✅ Good (Balanced explanation):

markdown

### 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):

markdown

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

✅ Good (Feature verification + Technical implementation):

markdown

**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]

Objectivity Examples

❌ Bad: "Best solution with no drawbacks. Approach 2 rejected: too complex."

✅ Good: "Selected Approach 1. Trade-off: losing Approach 2's 30% better throughput. Risk: may increase memory under edge case X."

Execution

Now start the task according to the guidelines above.