菜单
Build a clickable UI prototype as one self-contained HTML file (inline CSS, no build step, no framework) at docs/<feature-name>/prototype.html, opened straight in a browser. Trigger on "prototype this UI", "mock up this screen", "show me what this would look like", or wanting to click through a layout first.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | dev-ui-design |
| description | Build a clickable UI prototype as one self-contained HTML file (inline CSS, no build step, no framework) at docs/<feature-name>/prototype.html, opened straight in a browser. Trigger on "prototype this UI", "mock up this screen", "show me what this would look like", or wanting to click through a layout first. |
| argument-hint | [lite|full|ultra] |
A prototype answers "does this layout/flow feel right?" faster than real components can — no build step, no routing, no state library, just one HTML file someone opens in a browser and clicks through. If dev-design already wrote a UI/UX axis in docs/<feature-name>/DESIGN.md, this skill turns that text wireframe into something clickable; if not, it starts fresh from the request.
Throwaway by design. Nothing here becomes production code — inline styles, no components, no build tooling, copy-pasted markup over reusable abstractions. The moment it's approved, real implementation starts from scratch using the project's actual stack; the prototype's job is to be looked at and clicked, not maintained.
lite | full | ultra, default lite)Mode is the trailing argument when it is exactly lite, full, or ultra; everything else is the task/feature description. No mode given → lite.
lite — one screen or one flow, one state each (happy path).full — the flow's key states too (empty, loading, error, filled) as separate views the user can jump between (anchor links or a simple tab toggle — still no framework).ultra — light and dark variants, plus a couple of viewport breakpoints (mobile/desktop) demoed via CSS @media, not separate files.Artifact paths below are relative to the artifact root: docs/ by default, or wherever the user (or
dev-loop, which passes the one it resolved) points it. A gitignored or out-of-repo root means the
artifacts are scratch — write and read them as normal, but never commit them.
A prototype that looks like nothing else in the app is a worse prototype, not a bolder one.
ls docs/<feature-name>/DESIGN.md 2>/dev/null
grep -rln "<related component/screen name>" --include="*.css" --include="*.tsx" --include="*.html" | head
Read the ## UI / UX section of DESIGN.md if it exists. Skim 2-3 existing screens/components for the real product's spacing scale, type scale, color palette, and component conventions (buttons, cards, form fields) — match them loosely so the prototype reads as "this app" rather than a generic template. Don't chase pixel-perfect fidelity; that's what real implementation is for.
Everything inline — <style> in <head>, no external stylesheet, no CDN script tags, no JS framework. A few lines of vanilla <script> are fine for tab-toggling between states; nothing that needs npm install or a bundler.
<button>, <nav>, <label>) so it's actually clickable/keyboard-navigable, not just <div> soup.max-width, flex/grid) so it doesn't visibly break at normal window sizes — skip exhaustive breakpoint tuning unless ultra.Open the mental checklist, not the file: does every interactive element look clickable, do the states requested in Delivery Mode all exist, does it visually belong next to the app's real screens. Fix what's off before reporting done — the point is to save the user a round trip, not create one.
Save to docs/<feature-name>/prototype.html. Report the file path and how to view it (open docs/<feature-name>/prototype.html or equivalent for the user's OS), which states/variants it covers, and one line on what it was matched against in §1.
Commit hygiene and message style: see the git-safe skill (no Co-authored-by:, git add -u not -A, imperative why-focused subject).
git add docs/<feature-name>/prototype.html && git commit -m "prototype: <feature-name> UI". No push, no PR — the prototype travels with the feature branch, same as research and design.
Write documentation someone will actually read — READMEs, guides, API references, runbooks — short, scannable, example-first, and verified against the code. Trigger on "write docs", "document this", "write a README", "explain how to use this", "our docs are too long/confusing", or a doc that needs rewriting for humans.
Review a diff, branch, or PR for correctness bugs, security issues, and simplification opportunities; findings to docs/<feature-name>/REVIEW.md. Trigger on "review this", "code review", "security review", "audit this", or after something is implemented and needs checking before merge.
Write docs/<feature-name>/PLAN.md with phased, checkbox-driven steps for a feature, refactor, upgrade, or infrastructure change. Trigger on "create/make a plan", "plan this feature/refactor/upgrade", any request to document steps before coding, and proactively when complexity warrants a written plan.
Decide a feature's shape before planning — system design, data model, API contract, UI/UX, whichever apply — and write docs/<feature-name>/DESIGN.md. Trigger on "design this feature/API/schema/UI", "how should we structure this", or between dev-research and dev-create-plan.
Execute an implementation plan from docs/<feature-name>/PLAN.md — tick checkboxes, commit each phase. Trigger on "implement/execute/continue/resume the plan", "start phase 1", "go" right after a plan was created, or whenever there is a PLAN.md to build, even if the user never says "plan".
Run an autonomous plan → implement → review loop for a feature, iterating until the code review passes and pausing for approval before pushing. Use on "loop on this", "keep going until it passes review", "autonomous dev loop", "plan implement and review", or a self-correcting agent workflow.