Design variations
Skill MaybeMonad/skills/skills/design-workflow/design-variations
npx -y skills add MaybeMonad/skills --skill design-variationsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Design variation workflow for options, alternatives, wireframes, multiple takes, visual explorations, layout comparisons, flow comparisons, or taste discovery before committing to one direction.
SKILL.md
2.8 KB, as published. Nobody here has run it
Design Variations
Use this skill when seeing alternatives is the cheapest way to find the right design. Variations should test real design decisions, not cosmetic swaps.
Workflow
- Define the decision surface:
- Screen, component, flow, page, deck section, visual direction, interaction model, or content hierarchy.
- Completion criterion: the scope and comparison unit are clear.
- Establish the baseline:
- Existing system to preserve, source-map constraints, user-supplied copy, target medium, audience, and fidelity level.
- Completion criterion: each variation starts from the same real brief.
- Pick axes worth testing:
- Layout, hierarchy, density, visual tone, typography, interaction model, information architecture, copy strategy, component style, or motion.
- Completion criterion: each axis can change the final implementation or product judgment.
- Produce distinct options:
- Prefer 3 options by default: safe, refined, and edge.
- Use 2 when scope is narrow and 4-5 only when the user asked for breadth.
- Completion criterion: any two options differ in more than color, radius, shadow, or accent treatment.
- Present for comparison:
- Keep options in one artifact when practical: one file, canvas, storyboard, toggle panel, or compact table.
- Label each option by what it tests and the tradeoff it carries.
- Completion criterion: the user can compare without opening scattered files or guessing what changed.
- Recommend:
- Pick a default and a backup.
- Name what to borrow from rejected options if useful.
- Completion criterion: the recommendation links design taste to execution cost, risk, and fit.
Output Shape
- Decision surface.
- Axes tested.
- Options: label, design bet, what changes, tradeoffs, implementation impact.
- Recommendation: default, backup, and mix-and-match notes.
- Next step: direction lock, prototype, production implementation, or polish.
Rules
- Do not pad with cosmetic variants. If the only difference is color, drop it.
- Preserve exact copy and required semantics across options unless copy is an explicit variation axis.
- Use low-fidelity wireframes when structure is the unknown; use hi-fi when visual taste is the unknown.
- Avoid durable backend, auth, payment, migration, or production data changes while the design choice is still unresolved.
Credit
Inspired by Trystan-SA/claude-design-system-prompt (MIT), especially its variation and wireframe workflows.