Design workflow
Skill MaybeMonad/skills/skills/design-workflow/design-workflow
npx -y skills add MaybeMonad/skills --skill design-workflowAssembled 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 workflow router for UI, page, app screen, prototype, deck, design-system, visual-direction, variation, or polish work. Use when the user asks for design help and the next step may be source-map extraction, aesthetic direction, options, prototyping, or final quality review.
SKILL.md
3.4 KB, as published. Nobody here has run it
Design Workflow
Use this skill as the suite entrypoint for design work. The job is to keep the artifact grounded in the real source system, the user's taste, and the medium being designed for.
Phase Map
Source-first setup:
design-source-map: extract tokens, components, layout grammar, density, interaction patterns, assets, and gaps from an existing product, codebase, brand guide, screenshot set, Figma file, or reference site.
Direction setting:
design-direction: commit to a concrete visual system when no existing design system applies, or when the user asks for a new look.
Exploration:
design-variations: produce meaningfully different options when the user wants alternatives, wireframes, visual directions, or comparison before durable implementation.
Interactive build:
design-prototype: build a clickable prototype or usable front-end slice with real state, transitions, validation, and feedback.
Review and repair:
design-polish: run the final quality gate across source fidelity, accessibility, generic-AI tropes, hierarchy, rhythm, interaction states, responsiveness, and content fit.
Selection Rules
- If a real system, brand, screenshot, Figma file, or existing codebase exists,
start with
design-source-mapbefore inventing visuals. - If no system exists, use
design-directionbefore drawing hi-fi screens. - If the user can judge taste only after seeing options, use
design-variationsbefore changing durable app code. - If the user asks for a prototype, demo, mockup, clickable flow, or usable
app-like artifact, use
design-prototype. - If a design is already built or about to be shown, shipped, screenshotted, or
handed off, use
design-polish. - Do not run every skill by default. Choose the smallest chain that resolves the highest-cost unknown.
Operating Rules
- Inspect available sources before asking questions that files, screenshots, docs, runtime, or current code can answer.
- Separate source facts, design judgments, assumptions, and uninspected areas.
- Preserve exact user-supplied product, legal, pricing, SEO, and marketing copy unless the user asks for rewriting.
- Match the medium. Apps, dashboards, decks, landing pages, games, documents, and prototypes need different density, hierarchy, and interaction standards.
- Verify visual and interactive work in the runtime when possible. A passing build is not a design acceptance test.
Default Output
When asked to choose the design path, return:
- Recommended path: the smallest skill chain.
- Source context: inspected references and missing references.
- Design constraints: tokens, components, audience, medium, and non-goals.
- Immediate artifact: source map, direction, variation set, prototype, or polish report.
- Blocking questions: only questions whose answers change the next step.
Credit
Inspired by Trystan-SA/claude-design-system-prompt (MIT). This version is adapted for the MaybeMonad skills repository and uses this repo's source-first workflow style.