菜单
Use as a supporting skill for substantial production UI intended to ship when hierarchy, interaction, responsive behavior, accessibility, or visible states need an explicit build/review contract. Do not trigger for tiny copy/style changes, invisible frontend plumbing, or bounded mockups and throwaway prototypes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use for an actual ready, non-draft GitLab merge request review, re-review, or approval decision when current discussions, diff, CI, scope, findings, and approval state must be checked. Do not trigger for casual MR discussion, draft/WIP work, GitHub PRs, or local code review.
Use at conversation start, after context recovery, and for non-trivial engineering work to select exactly one primary workflow path plus one task-wide assurance and verification budget. Loading this router does not create artifacts, launch agents, or activate every workflow module.
Use only when creating, resuming, inspecting, updating, completing, or writing artifacts for an authorized .workflow plan or audit run through the bundled Workflow MCP tools. It is an operations contract, not a reason to create workflow artifacts.
Use when an authorized, sufficiently clear change needs a durable decision-complete plan under .workflow because execution is multi-step, risky, resumable, or explicitly requested. Do not create a plan for fast local work or read-only discussion.
Use at conversation start, after compaction or context recovery, and before Agent Memory reads or writes to decide whether durable global or project knowledge can materially change the task. Keep startup reads focused, and do not mutate memory during read-only or no-edits work unless the user explicitly asks to remember something.
Use after intent routing only when unresolved requirements, product intent, architecture, constraints, or tradeoffs can materially change scope, risk, acceptance criteria, or user-visible behavior. Inspect discoverable facts first and avoid exhaustive questioning.
| name | ui-contract |
| description | Use as a supporting skill for substantial production UI intended to ship when hierarchy, interaction, responsive behavior, accessibility, or visible states need an explicit build/review contract. Do not trigger for tiny copy/style changes, invisible frontend plumbing, or bounded mockups and throwaway prototypes. |
Support substantial production UI without creating an independent workflow or agent budget. The active primary path owns planning, execution, and completion.
If this skill is explicitly invoked for a bounded mockup, landing-page concept, or throwaway prototype:
fast;Do not invent production state matrices, extra breakpoints, accessibility programs, or reusable behavior for a bounded concept.
Before substantial undecided production UI implementation, create or update the active plan's ui-contract.md. Include only acceptance-relevant details:
Do not include vague taste language or states outside accepted scope. Execution must treat the contract as an acceptance source; update decisions.md before intentional drift.
Before completing substantial production UI, review once against the contract and runnable browser evidence. Check only accepted viewports and states. Record UI_PASS or UI_REVISE plus concrete Important, Minor, or Polish findings under artifacts/ui-review/ when a plan exists; otherwise report in chat.
An independent UI reviewer is optional, consumes the existing task-wide budget, and requires the same benefit gate as any other agent. Screenshots do not replace relevant code verification, and code checks do not replace the scoped visual pass.
Stop on UI_PASS. Polish does not extend the loop unless requested.