architecture-principle…
Architecture principles for manifest-dev: how its maintainer wants skills, wrappers, references, state and the workflow…
Guide visual and interaction design from the person, moment, and subject, with composable guidance for artifacts and creative directions. Use when creating or restyling a page, app, document, presentation, graphic, or prototype, or choosing how it should look and feel.
Claude Code
$ npx -y skills add doodledood/manifest-dev --skill design --agent claude-code
Codex
$ npx skills add doodledood/manifest-dev --skill design -a codex -y
Cursor
$ npx skills add doodledood/manifest-dev --skill design -a cursor -y
Gemini CLI
$ npx skills add doodledood/manifest-dev --skill design -a gemini-cli -y
GitHub Copilot
$ npx skills add doodledood/manifest-dev --skill design -a github-copilot -y
OpenCode
$ npx skills add doodledood/manifest-dev --skill design -a opencode -y
Windsurf
$ npx skills add doodledood/manifest-dev --skill design -a windsurf -y
name: design description: 'Guide visual and interaction design from the person, moment, and subject, with composable guidance for artifacts and creative directions. Use when creating or restyling a page, app, document, presentation, graphic, or prototype, or choosing how it should look and feel.' argument-hint: '<artifact, brief or existing file>' user-invocable: true
Design for a person in a moment: who is here, what they came to do, and how long they'll stay — a first glance, a meeting, a working day. Know what we want from them too — to understand something, act, trust us, come back — and make the design serve both at once. Make them feel what that moment wants, as strongly as it wants — quiet to spectacular — unless the request says otherwise. Find the visual idea in the subject and in their world, and take palette, type and texture from there rather than from a house style.
The person's attention is the budget. At each moment — a first screen, a slide, the step of a task — decide what matters most for what they came to do and what we want from them, and give it the most, boldly where the moment wants it; everything else supports it or waits. Find those moments by walking the person's journeys first: each scenario they arrive with — the first time, the everyday task, something gone wrong — and the steps it takes. Each step shows what that step needs; the rest stays one step away. Designs most often go wrong in the ways below: spending attention badly, or giving the idea too thin a form. These are defaults to avoid, not rules: use one whenever the request asks for it or the subject and moment call for it.
It's done when, looking once as that person at each of those moments, they get what they came for, we get what we wanted, it feels the way the moment asks, and nothing is left whose removal they'd miss. Take that look as a squint, blurred or shrunk: what the eye lands on first, and the path it follows from there, is what that moment needs, for them and for us, with nothing secondary louder. Stop there; further passes are refinement the requester can ask for.
Establish the intended use, supported claims, available assets, and constraints from the request, conversation, and project. Fill these in where the evidence is clear. Ask focused questions when missing information or unresolved alternatives would materially change the design, offering concrete options for creative choices; wait for those answers before committing to affected choices, and proceed with the rest. When the open alternative is an experience choice — where something lives, how the person moves through it, what each step asks — show two or three variants that differ on that choice, made from the product's existing patterns, and let the requester choose by looking, rather than asking about it in prose. With no person present to answer or choose, as when a run nobody is watching calls this skill, decide each such question and choice from the request, the project and the product's existing patterns, and name each one, with the alternatives not taken, first in what you report. State reasonable assumptions for minor gaps and proceed. Choose visual techniques that suit the concept and the constraints.
Explicit requirements and an existing design system outrank this. Make any proposed departure explicit. When refining existing work, keep what works and change what the feedback names; keep a narrow refinement within its existing direction, reading only guidance bearing on the change.
Before composing a new artifact or substantially redesigning one, identify its uses and choose the creative direction or combination that serves its goal. Infer these choices from the request and context, honoring explicit preferences. Use the indexes to select and read only the relevant guides. For substantial work, briefly state the chosen approach and why.
| Question | Index | |---|---| | How will someone use the artifact? | [Artifact guides](references/artifacts/index.md) | | What feeling and visual character will serve that use? | [Creative directions](references/directions/index.md) |
These are non-exhaustive repertoires, not required categories. Combine or invent approaches when the brief calls for them. In a blend, give the design a coherent center and use supporting qualities where they help; do not st
Hand your agent a task. Get back work you can trust. manifest-dev is a set of free, open-source skills for coding agents.
Architecture principles for manifest-dev: how its maintainer wants skills, wrappers, references, state and the workflow…
Ship a change to a file setup-project copies or emits into projects (ADR_FORMAT.md, NORTH_STAR_FORMAT.md, the verification…
Design principles for manifest-dev: how its maintainer wants the visual and interaction design guidance the plugin ships, and the…
Harden a manifest-dev task guidance file for one-shot quality — either /define''s quality-gate/Default set or figure-out''s probe…
Analyze Claude Code sessions to learn what went right/wrong and suggest high-confidence improvements to skills. Use when asked to…
The red-flag lists mirrored between figure-out''s and define''s task files, so a change to one side lands on the other. Use when…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.