메뉴
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 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
| 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.