From spk
Run a design shotgun exploration: generate multiple distinct UI directions, compare them side-by-side, collect feedback, and lock an approved design direction before implementation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/spk:design-shotgun [screen, product area, URL, screenshot, or rough UI idea][screen, product area, URL, screenshot, or rough UI idea]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this when the user wants to explore visual directions before committing to implementation: "show me design options", "I don't like this UI", "visual brainstorm", "ทำ design shotgun", "ขอหลายแบบให้เลือก", or "make this screen look better".
Use this when the user wants to explore visual directions before committing to implementation: "show me design options", "I don't like this UI", "visual brainstorm", "ทำ design shotgun", "ขอหลายแบบให้เลือก", or "make this screen look better".
This is adapted from GStack's design-shotgun idea, but SPK keeps it local, lightweight, and codebase-aware: generate disposable variants, create a comparison board, collect structured feedback, then hand the approved direction to /spk:code.
!git status --short
!git log -3 --oneline
!find . -maxdepth 3 \( -name DESIGN.md -o -name CLAUDE.md -o -name AGENTS.md -o -name package.json -o -name tsconfig.json -o -name vite.config.* -o -name next.config.* \) -not -path './node_modules/*' -not -path './.git/*' -not -path './dist/*' -not -path './build/*' | sort | head -100
!find .spk/design-shotgun -maxdepth 3 -name approved.json 2>/dev/null | sort | tail -10
Dispatch: Task(subagent_type="spk:designer", prompt="Run SPK design-shotgun for: $ARGUMENTS. Generate multiple distinct design variants before implementation. First inspect DESIGN.md if present, relevant app/routes/components, and prior .spk/design-shotgun approved.json files. Gather only missing context that materially changes the design: audience, job-to-be-done, current screen/URL/screenshot, constraints, and variant count (default 3). Then create 3 distinct concepts with different layout, typography, palette, density, and product emphasis. Produce disposable local artifacts under .spk/design-shotgun/<screen>-<date>/: variant HTML mockups or images when tools allow, README notes, and a board.html comparison page. Use realistic product copy and edge cases. If browser/screenshot tooling is available, visually QA each variant and fix obvious rendering bugs. Do not modify production source code. Return a head-to-head comparison, one opinionated recommendation, artifact paths, and ask the user to choose A/B/C, remix, or approve for implementation. After explicit user approval, save approved.json with variant, feedback, timestamp, and implementation notes.")
Expect: variant artifacts, comparison board path, visual QA notes, and a recommended direction. No production source changes unless the user explicitly asks for implementation.
DESIGN.md, current routes/components, existing screenshots/URLs, and previous approved designs.board.html so the user can compare all variants side-by-side.approved.json only after confirmation. /spk:code can then implement the approved direction.DESIGN.md unless the user asks to explore outside the design system..spk/design-shotgun/<screen>-YYYYMMDD-HHMM/
├── board.html
├── README.md
├── variant-a.html
├── variant-b.html
├── variant-c.html
├── screenshots/ # optional visual QA proof
└── approved.json # only after user confirmation
approved.json shape:
{
"screen": "<screen>",
"approved_variant": "A",
"feedback": "<what the user liked and wants changed>",
"implementation_notes": ["<specific guidance for /spk:code>"],
"date": "<UTC timestamp>",
"branch": "<git branch>"
}
## Design Shotgun Results
- Artifact dir: `.spk/design-shotgun/<screen>-<date>/`
- Board: `.spk/design-shotgun/<screen>-<date>/board.html`
- Variants: A <name>, B <name>, C <name>
### Head-to-head
- A: <strength> / <weakness>
- B: <strength> / <weakness>
- C: <strength> / <weakness>
Recommendation: <one opinionated pick and why>
Next: pick A/B/C, ask for a remix, or approve for `/spk:code`.
/spk:plan, return the approved design direction as planning input rather than writing source code.Inspired by Garry Tan's GStack design-shotgun workflow: multiple visual variants, comparison board, structured feedback, and taste memory. This SPK version is intentionally lightweight and repo-local.
npx claudepluginhub apipoj/spk --plugin spkGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.