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
- Confirm design reference with
AskUserQuestion:
- Screenshot / image: Receive file path and read with
Read
- Verbal description: Receive as text
- Both: Image + supplemental description
- 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
- 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.
| User input |
What to clarify |
How to ask |
| "Ugly", "Meh", "Not great" |
What specifically bothers them |
Options: colors / layout / font / spacing / overall impression / other |
| "Make it nicer" |
Ideal image |
Options: simple-clean / modern-refined / warm-friendly / bold-impactful + reference sites |
| "Change this" (location unclear) |
Specific area |
Options from screen sections or ask for screenshot |
| "Hard to use" |
What they tried to do |
Ask specific scenario: which action / what happened / what they expected |
| "Want it aligned/consistent" |
What's the reference |
Options: match existing screen / new direction + reference screen if any |
2-2: Gather Change Details
Use AskUserQuestion to gather (skip what's known from arguments/images):
- What to change: Which part, how to change it (skip if clarified in 2-1)
- Reason/background: Why the change is needed (optional)
- 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):
| Situation |
What to ask |
| Layout change |
Behavior per screen size |
| Color/font change |
Specific values or reference sites |
| New element |
Placement, sizing, interactions |
| Animation |
Timing, type, reference examples |
| Multi-screen impact |
Impact scope confirmation |
| Conditional display |
Which conditions, what display |
| "Leave it to you" |
Investigate code then present multiple options |
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
- Identify target component — Search by screen/component name with
Grep/Glob. Use Explore agent if needed
- Understand current state — Check current styling, layout, component structure
- Check impact scope — Other screens using same component, shared styles
- Check design foundation — Theme settings, design tokens, available existing components
Phase 4: Preview and Output Destination
- Create draft from gathered info and investigation (see
templates/issue.md)
- Show preview to user
- Apply revisions if any (repeat until satisfied)
- 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
| Priority |
Criteria |
| Urgent |
Severely harms user experience, release blocker |
| High |
Major screen appearance issue, brand inconsistency |
| Medium |
Nice to improve, can be addressed next release |
| Low |
Fine-tuning, address when time permits |
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
1---2name: design-request-en3description: Gather design change requests through interactive dialog and create a structured Issue.4---56**Language: Always interact with the user in 日本語.**78# design-request-en910Organize design change requests through dialog with design references (screenshots, mockups, verbal description) and create an actionable Issue. Usable by non-engineers.1112## Prerequisites1314- Claude Code environment15- `gh` CLI (for GitHub Issue output)1617## Arguments1819- **Text / image path** (e.g., `/design-request-en Want to change the header design`): Use as initial info, interview for missing details20- **No arguments**: Start interviewing from scratch2122## Phase 1: Design Reference and Project Scan23241. Confirm design reference with `AskUserQuestion`:25 - **Screenshot / image**: Receive file path and read with `Read`26 - **Verbal description**: Receive as text27 - **Both**: Image + supplemental description282. **Lightweight project scan** (to ground interview options in reality):29 - Identify screens/pages from directory structure (`pages/`, `views/`, `routes/`, etc.)30 - Identify component directory structure (`components/`, etc.)31 - Identify framework and CSS library323. Confirm target screen/component with **scan-based options**3334## Phase 2: Interview3536**Ask in plain language without technical jargon.**37**Carefully clarify vague requests until they're concrete enough to implement.**3839#### 2-1: Disambiguate Vague Requests4041When user input is vague, make it concrete. **Prefer offering options over free-form input.**4243| User input | What to clarify | How to ask |44|------------|----------------|-----------|45| "Ugly", "Meh", "Not great" | What specifically bothers them | Options: colors / layout / font / spacing / overall impression / other |46| "Make it nicer" | Ideal image | Options: simple-clean / modern-refined / warm-friendly / bold-impactful + reference sites |47| "Change this" (location unclear) | Specific area | Options from screen sections or ask for screenshot |48| "Hard to use" | What they tried to do | Ask specific scenario: which action / what happened / what they expected |49| "Want it aligned/consistent" | What's the reference | Options: match existing screen / new direction + reference screen if any |5051#### 2-2: Gather Change Details5253Use `AskUserQuestion` to gather (skip what's known from arguments/images):541. **What to change**: Which part, how to change it (skip if clarified in 2-1)552. **Reason/background**: Why the change is needed (optional)563. **Priority**: Urgent or next release is fine5758#### 2-3: Follow-up Questions5960Ask **only what's needed** based on responses (max 3, don't ask what can be inferred):6162| Situation | What to ask |63|-----------|-------------|64| Layout change | Behavior per screen size |65| Color/font change | Specific values or reference sites |66| New element | Placement, sizing, interactions |67| Animation | Timing, type, reference examples |68| Multi-screen impact | Impact scope confirmation |69| Conditional display | Which conditions, what display |70| "Leave it to you" | Investigate code then present multiple options |7172#### 2-4: Confirm Understanding7374After interview, **summarize understanding in bullet points and confirm with user**.75Repeat corrections until agreement, then proceed to Phase 3.7677## Phase 3: Codebase Investigation78791. **Identify target component** — Search by screen/component name with `Grep`/`Glob`. Use `Explore` agent if needed802. **Understand current state** — Check current styling, layout, component structure813. **Check impact scope** — Other screens using same component, shared styles824. **Check design foundation** — Theme settings, design tokens, available existing components8384## Phase 4: Preview and Output Destination85861. Create draft from gathered info and investigation (see `templates/issue.md`)872. Show preview to user883. Apply revisions if any (repeat until satisfied)894. Confirm output destination with `AskUserQuestion`:90 - **Create GitHub Issue** (recommended): `design: <change summary>` format91 - **Save as local MD file**: Generate in project root92 - **Append to existing Issue**: Specify Issue number to add as comment9394## Phase 5: Output9596#### GitHub Issue (new)97- Create with `gh issue create`, title `design: <change summary>`, label `design`98- Report URL to user99100#### Append to Existing Issue101- Add as comment with `gh issue comment <number>`102- Report URL to user103104#### Local MD105- Generate `design-request-<summary-kebab-case>.md` in project root106- Report path to user107108## Priority Criteria109110| Priority | Criteria |111|----------|----------|112| Urgent | Severely harms user experience, release blocker |113| High | Major screen appearance issue, brand inconsistency |114| Medium | Nice to improve, can be addressed next release |115| Low | Fine-tuning, address when time permits |116117## Rules118119- **No technical jargon** in interviews. Mirror user's own terms only120- `AskUserQuestion` options must be **based on project scan results**. Never include screens/components that don't exist in the project121- **Minimal questions**. Don't ask what can be inferred122- Code investigation must **verify against actual code**, not guess123- Issues must clearly state **before state and expected after state**124- **Always preview and get user approval** before creating Issue125- Do not modify code. Output is Issue only
diegosouzapw