菜单
Mandatory design-brief gate for Product Design build and design workflows. Use before ideation, prototyping, image-to-code builds, redesigns, or product UI work to clarify missing product, visual, and interactivity context or play back the supplied brief before proceeding.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audit or critique a product flow, journey, workflow, funnel, onboarding path, checkout path, settings path, screen, or multi-step product experience by capturing screenshots first, placing them in Figma or a local folder, then reporting UX, design, and accessibility findings from that evidence. Use when the user asks to audit, critique, review, inspect, assess, or evaluate a product experience.
Generate image-based visual alternatives, remixes, or concept directions after Product Design get-context has confirmed the design brief. Use when the user asks for design variants, visual exploration, remixes, or image-generated approaches from provided context.
Implement a selected image, screenshot, mockup, or Image Gen reference as a faithful responsive frontend after Product Design get-context has confirmed the design brief.
Use to discover specific skills for the Product Design plugin, when it is at-mentioned directly, or for any mentions of potentially relevant work, including: UX research; product, screen, or flow audits; visual ideation; app or interface design, redesign, cloning, prototyping, or implementation from ideas, URLs, images, Figma, or code; design QA; and prototype sharing or deployment.
Route coded prototype requests after Product Design get-context has confirmed the design brief. Use for building prototypes from URLs, images, mockups, Figma, existing code, or ideas that need visual exploration before build.
Clone a live URL as a runnable frontend-only local app using Browser/Chrome source evidence after Product Design get-context has confirmed the design brief.
| name | get-context |
| description | Mandatory design-brief gate for Product Design build and design workflows. Use before ideation, prototyping, image-to-code builds, redesigns, or product UI work to clarify missing product, visual, and interactivity context or play back the supplied brief before proceeding. |
| allowed_tools | ["AskUserQuestion"] |
Gather only the context needed for the next design action. This skill resolves or confirms the design brief; it does not implement UI or create durable design artifacts.
Run this skill at the start of Product Design requests that ask to design, build, prototype, clone, redesign, extend, or generate product UI directions.
Use question mode when any of the following are unclear:
In question mode, ask via the AskUserQuestion tool (structured multiple-choice), not free-form prose. Bundle the unclear items into one AskUserQuestion call with multiple questions so the user can answer in one pass. The UI always offers an Other/custom-text choice, so the user can still type a free answer. Only fall back to plain-text questions if the AskUserQuestion tool is unavailable.
Use playback mode when the user already provided the needed details. In playback mode, do not re-ask answered questions; play back the brief in a pithy format and name the next workflow.
Hard boundary: do not implement UI, scaffold a prototype, start a server, or create files while context is still missing.
Before starting, load $user-context and run its preflight script when local shell access is available.
Use saved product URLs, Figma files, screenshots, reference images, codebase paths, Storybook, tokens, design systems, brand assets, component refs, browser preferences, and share targets as grounding material when relevant.
Do not inspect every saved reference. Inspect only what the current task needs.
The following three areas should be answered by the user. Adapt the questions based on what the user has provided so far in the conversation. If some or all fields are already known, skip the questions and summarize the design brief in your own words.
Ask the unclear ones in a single AskUserQuestion call (one entry per unclear area). Each question needs 2-4 concise options plus a short header chip; the UI auto-adds an Other/custom choice for free-form answers.
The three areas to resolve are:
Example AskUserQuestion call (adapt options to the actual request):
{
"questions": [
{
"header": "目标",
"question": "这个页面/产品主要要做什么？",
"options": [
{ "label": "品牌展示官网", "description": "突出品牌形象与卖点的展示型页面" },
{ "label": "可下单/转化", "description": "包含下单、预约或留资等转化动作" },
{ "label": "信息/内容站", "description": "以内容浏览、列表与详情为主" }
]
},
{
"header": "视觉风格",
"question": "有没有要参照的视觉来源？没有的话想要什么风格？",
"options": [
{ "label": "高级/精致", "description": "克制留白、精致排版与动效，高端质感" },
{ "label": "大胆/个性", "description": "强烈主色、夸张排版，记忆点突出" },
{ "label": "参照某个网址/截图", "description": "我会提供 URL 或设计稿来匹配" }
]
},
{
"header": "交互度",
"question": "需要多少交互？",
"options": [
{ "label": "完整交互", "description": "控件、状态、表单等都真实可用" },
{ "label": "偏静态", "description": "以视觉为主，控件最小交互，出得更快" }
]
}
]
}
Before proceeding to $ideate, $prototype, $url-to-code, or $image-to-code, confirm the design brief by explaining it back to the user in a pithy format as a final message.
Proceed only after the user confirms the design brief, unless the current thread already contains confirmation of that exact brief. If the user provides feedback, continue to refine the design brief with them.
After the user confirms the design brief, send one short expectation-setting note before starting an involved app, prototype, clone, redesign, or build. Example confirmation message with expectations setting:
Lovely, brief locked. This kind of build usually takes about 10-15 minutes, and ambitious ones can take longer. Good moment to grab coffee or tend to something else; I'll keep moving and bring the prototype back when it is ready.
Do not send this note for tiny static changes, quick audits, simple research, setup-only, or share-only requests.
Done means the user has confirmed the design brief.