Design Request En

Phase 2: Interview

Ask in plain language without technical jargon. Carefully clarify vague requests until they're concrete enough to implement.

2-1: Disambiguate Vague Requests

When user input is vague, make it concrete. Prefer offering options over free-form input.

2-2: Gather Change Details

Use AskUserQuestion to gather (skip what's known from arguments/images):

1. What to change: Which part, how to change it (skip if clarified in 2-1)
2. Reason/background: Why the change is needed (optional)
3. Priority: Urgent or next release is fine

2-3: Follow-up Questions

Ask only what's needed based on responses (max 3, don't ask what can be inferred):

2-4: Confirm Understanding

After interview, summarize understanding in bullet points and confirm with user. Repeat corrections until agreement, then proceed to Phase 3.

Phase 3: Codebase Investigation

1. Identify target component — Search by screen/component name with Grep/Glob. Use Explore agent if needed
2. Understand current state — Check current styling, layout, component structure
3. Check impact scope — Other screens using same component, shared styles
4. Check design foundation — Theme settings, design tokens, available existing components

Phase 4: Preview and Output Destination

1. Create draft from gathered info and investigation (see templates/issue.md)
2. Show preview to user
3. Apply revisions if any (repeat until satisfied)
4. Confirm output destination with AskUserQuestion:
   • Create GitHub Issue (recommended): design: <change summary> format
   • Save as local MD file: Generate in project root
   • Append to existing Issue: Specify Issue number to add as comment

Phase 5: Output

GitHub Issue (new)

• Create with gh issue create, title design: <change summary>, label design
• Report URL to user

Append to Existing Issue

• Add as comment with gh issue comment <number>
• Report URL to user

Local MD

• Generate design-request-<summary-kebab-case>.md in project root
• Report path to user

Priority Criteria

Rules

• No technical jargon in interviews. Mirror user's own terms only
• AskUserQuestion options must be based on project scan results. Never include screens/components that don't exist in the project
• Minimal questions. Don't ask what can be inferred
• Code investigation must verify against actual code, not guess
• Issues must clearly state before state and expected after state
• Always preview and get user approval before creating Issue
• Do not modify code. Output is Issue only