菜单
Use when building or redesigning a product UI/visual system — creating a design system, writing or following a DESIGN.md contract, generating screens in a design tool (Stitch/Figma) then porting to code, or doing a branded visual redesign.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when orchestrating multi-agent or long-running work — spawning sub-agents, fanning out parallel tasks, delegating subtasks, running build-then-review loops, or deciding which model tier should do a piece of work.
Use when building a self-contained shippable artifact from scratch or a major rev — an MCP server, a CLI, a library/SDK, a skills pack, a plugin — anything that gets packaged and released rather than merged into an existing app.
Use when maintaining project state across sessions — writing or reading a STATE.md / MEMORY.md, recording what was learned, resuming interrupted work, or deciding what to persist for future sessions.
Use during hands-on execution of any coding or agent task — especially when following multi-item instructions, deciding how much to deliberate, about to claim something is done, or producing output at risk of reading as generic AI slop.
Use when building or running an automated measurement/audit/reporting pipeline that scores many subjects on a recurring basis and reports to stakeholders — a compliance monitor, a benchmark matrix, a metrics dashboard, a scheduled scan-and-report.
Use when planning, building, or reviewing a software milestone/release/version — any task framed as "ship vX", "build the next milestone", "plan and execute a feature set", "do a research + build pass", or "review what we shipped".
| name | design-workflow |
| description | Use when building or redesigning a product UI/visual system — creating a design system, writing or following a DESIGN.md contract, generating screens in a design tool (Stitch/Figma) then porting to code, or doing a branded visual redesign. |
For building a product's look — a design system and the screens that follow it —
as opposed to wiring features (milestone-workflow) or shipping a library
(artifact-build). The spine: a DESIGN.md contract is the source of truth;
tool-generated screens and ported code both conform to it.
Read the repo's CLAUDE.md first for the stack and where design docs live.
A single DESIGN.md is the design source of truth, written to be read
end-to-end before generating any page — "do not paraphrase, summarize, or skip
sections." It hard-codes:
When using a design tool (Stitch, Figma) to generate screens:
code.html + a rendered screen.png per screen) as the reference.A visual system v2 doesn't silently overwrite v1 — write a new spec that explicitly supersedes the old contract and names which rules it overrides (e.g. "v2 supersedes v1, specifically its no-shadows rule"), validate it visually against an example before porting, then roll it across all surfaces. Brainstorm → spec → plan, same as any build.
This skill is the process/contract layer. For the aesthetic-judgment layer —
making distinctive, non-templated visual choices — Anthropic's official
frontend-design skill is the companion (brainstorm → critique → build, signature
element, and the anti-default calibration: avoid the AI-cliché looks of
cream+serif+terracotta, near-black+acid accent, or broadsheet hairlines unless the
brief asks for them). Use it for the look; use this for the workflow.
Honesty in copy and numbers above all; match the surrounding code's idioms when
porting; verify each screen against the contract before moving on; respect
prefers-reduced-motion for any motion; don't ship a screen the contract forbids.
See PROVENANCE.md for sources.