Awesome-omni-skill design-request-en

Gather design change requests through interactive dialog and create a structured Issue.

install

source · Clone the upstream repo

git clone https://github.com/diegosouzapw/awesome-omni-skill

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skill "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/design/design-request-en" ~/.claude/skills/diegosouzapw-awesome-omni-skill-design-request-en && rm -rf "$T"

manifest: skills/design/design-request-en/SKILL.md

source content

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