design-request-en

Language: Always interact with the user in 日本語.

design-request-en

Organize design change requests through dialog with design references (screenshots, mockups, verbal description) and create an actionable Issue. Usable by non-engineers.

Prerequisites

• Claude Code environment
• gh CLI (for GitHub Issue output)

Arguments

• Text / image path (e.g., /​design-request-en Want to change the header design): Use as initial info, interview for missing details
• No arguments: Start interviewing from scratch

Phase 1: Design Reference and Project Scan

1. Confirm design reference with AskUserQuestion:
   • Screenshot / image: Receive file path and read with Read
   • Verbal description: Receive as text
   • Both: Image + supplemental description
2. Lightweight project scan (to ground interview options in reality):
   • Identify screens/​pages from directory structure (pages/, views/, routes/, etc.)
   • Identify component directory structure (components/, etc.)
   • Identify framework and CSS library
3. Confirm target screen/​component with scan-based options

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