Menu
Use when you need 3-5 intentionally different UI directions before committing to a single design approach
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | design-shotgun |
| description | Use when you need 3-5 intentionally different UI directions before committing to a single design approach |
| allowed-tools | Read, Grep, Glob, Bash, AskUserQuestion |
Generate multiple intentional design directions for a feature brief or plan. This is divergence before commitment.
Do NOT write code. Do NOT edit the plan. Your output is design options plus a recommendation strong enough to carry into /product-review DESIGN or /plan-design-review.
$ARGUMENTS = brief text, plan path, or empty--count N = number of directions, default 3, clamp to 3-5docs/plans/Before inventing directions:
DESIGN.md, design-system docs, or existing UI patternsIf the repo already has a strong design language, push variation through hierarchy, interaction model, pacing, and emotional tone. Do not propose something that obviously fights the product's established visual system.
Produce N directions that are meaningfully different, not cosmetic reskins.
Each direction must include:
A short memorable label.
Two to three sentences describing the concept and the user impression it creates.
What the user sees first, second, and third.
What the main interaction pattern is:
How the concept changes on smaller screens. Not "stack it on mobile." Be specific.
What needs care so the design stays usable and credible.
Name the exact choices that keep it from becoming AI slop. If the direction still sounds like "clean modern cards," rewrite it.
Call out where this direction is easy, medium, or high risk for the current codebase.
After drafting the directions, compare them directly. If any two would produce roughly the same screen with different styling, rewrite until they diverge on structure or behavior.
Use a compact comparison table:
| Direction | Best For | Main Risk | Distinguishing Move |
|---|---|---|---|
| ... | ... | ... | ... |
Pick a single recommended direction and explain:
Finish with:
Give the user the exact next step:
/product-review DESIGN if the concept still needs product challenge/plan-design-review if a plan exists and needs design completionProvide a short block that can be pasted into a plan:
Recommended direction: ...
Primary user impression: ...
Hierarchy: ...
Interaction model: ...
Responsive posture: ...
Accessibility/trust requirements: ...
Must-not-lose differentiators: ...
Iterative review-fix loop for accumulated milestone/branch changes. Runs parallel reviewers, fixes findings autonomously, repeats until clean. Use after multiple tasks merge to a milestone branch, or before merging to main. Invoke with /milestone-review --base-branch main. Supports --dry-run and --max-iterations.
This skill should be used when the user wants a comprehensive code review using multiple specialized reviewers in parallel. Invoked with /multi-review or when user asks for 'thorough review', 'full code review', or 'review from multiple perspectives'. Use --plan <path> to review an implementation plan pre-coding.
Use when facing a bug, test failure, or unexpected behavior that isn't immediately obvious
Use when starting a new feature or idea that needs thorough pre-execution planning. Use instead of calling /product-review, /spec, and review skills individually.
Use when you have an idea, goal, or feature description and need to turn it into an actionable plan with tasks
Use when you need measured performance evidence by running a repeatable command on the current branch and a baseline ref