菜单
将需求文档转化为给 UI 设计师使用的设计说明文档。Use when 用户提到“需求文档转设计文档”“PRD 转 UI 文档”“生成为设计师准备的页面说明/交互说明/视觉交付文档”“把产品需求整理成设计 brief”等场景时务必使用。适用于单个需求文件、多个相关 Markdown 文档或需求目录；输入路径与输出路径必须支持用户指定或自动推断，不能写死为固定目录。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
按照已有 vibe coding todo list 逐项执行开发任务。如果任务列表文档不存在，自动调用 flowcode_todo 根据需求生成任务列表后再执行。Use when Codex 需要从现有 todos.md、任务清单或 wiki 生成的 todo list 中选择未完成任务，读取关联 wiki/文档，明确验收标准，做最小代码修改，运行验证，并在通过后更新 todo 状态；适用于"按照 todo list 执行""继续下一个任务""完成 Txx""批量执行前 N 个 todo"等场景。
从 wiki 索引生成 vibe coding 任务计划，并在需要时先调用 flowcode_wiki 生成或更新 wiki。如果涉及页面/UI 设计，在调用 flowcode_wiki 前先调用 flowcode_ui 定义页面设计规范。Use when Codex 需要根据现有 wiki 生成 todos，或用户给的是 Markdown 文档而目标是"先整理成 wiki 再生成任务计划"的综合流程；适用于要求任务由简单到复杂、每个任务链接到对应 wiki 小文档、且输入输出路径不能写死的场景。
Build a wiki-style knowledge base from a project's existing Markdown documentation files. Use when Codex is asked to analyze documentation, split long docs into smaller Markdown pages, create a central wiki index, add retrieval paths, relationship graphs, and cross-links, while using source docs as the only content source and avoiding unrelated file changes. Source and output directories are configurable, not hardcoded.
使用 Pencil MCP 在画布上进行 UI 设计、原型创建和设计系统管理。Use when the user asks to create UI designs, mockups, dashboards, landing pages, wireframes, design systems, or any visual design task using Pencil. Triggers on mentions of "设计"、"UI"、"原型"、"画布"、"dashboard"、"landing page"、"wireframe"、"设计系统"、"Pencil"。
| name | flowcode-ui |
| description | 将需求文档转化为给 UI 设计师使用的设计说明文档。Use when 用户提到“需求文档转设计文档”“PRD 转 UI 文档”“生成为设计师准备的页面说明/交互说明/视觉交付文档”“把产品需求整理成设计 brief”等场景时务必使用。适用于单个需求文件、多个相关 Markdown 文档或需求目录；输入路径与输出路径必须支持用户指定或自动推断，不能写死为固定目录。 |
把已有需求文档整理成一份 UI 设计师可直接消费的设计说明文档，用于后续页面设计、交互设计、视觉稿或原型制作。
这份文档的目标不是复述需求原文，而是把需求中和 UI 设计直接相关的信息重新组织为：
核心原则：自动运行，自主找方案，实在不能运行就停止。遇到问题时先自行分析并尝试解决，不等待用户介入；多个方案可选时，选择最优方案直接执行；只有确认无法继续时才停止任务并说明原因。
flowcode_design 的输入上下文。不要把路径写死。把路径视为可推断参数：
sourceReqPath 需求文档文件或目录
supportingDocs 补充文档列表（可选）
outputDoc UI 设计师文档输出文件
推断顺序：
requirement、requirements、prd、product、spec、需求、产品 的位置；如果存在多个候选且无法判断，按以下决策顺序处理：分析各候选的上下文与当前任务相关性，推断最优候选并执行；无法推断则停止任务并说明原因。sourceReqPath 是单个文件且用户没指定 outputDoc，默认输出到同目录，文件名为 <原文件名>.ui-designer.md。sourceReqPath 是目录且用户没指定 outputDoc，默认输出到该目录下的 ui-designer-spec.md。supportingDocs 只读取和当前需求直接相关的文档，不要顺手加载整个 docs/。在汇报中说明最终实际使用的路径。
优先读取以下输入：
不要默认读取：
如果需求引用了其他文档中的术语、状态或流程，再按需补读相关部分。
sourceReqPath 是单文件还是目录。supportingDocs。如果用户没有说清楚，但可以低风险推断，就先说明假设再执行；如果候选输入有多个，按以下决策顺序处理：分析各候选的上下文与当前任务相关性，推断最优候选并执行；无法推断则停止任务并说明原因。
从需求中重点提取这些信息：
不要把纯技术实现细节原样搬进 UI 文档，除非它直接影响设计，例如：
把原始需求重组为设计师易读结构，而不是照抄原文顺序。优先按“页面/模块/流程”组织。
对于每个页面或模块，尽量回答：
遇到以下情况时不要猜：
统一写入“待确认问题”，并注明来源段落或冲突点。
默认生成一份 Markdown 文档，推荐使用以下结构：
# UI 设计师文档：<需求主题>
## 1. 文档信息
- 来源需求：`<sourceReqPath>`
- 补充文档：`<supportingDocs，没有则写 无>`
- 输出目的：供 UI / 交互 / 视觉设计使用
## 2. 需求摘要
- 目标
- 本次范围
- 非本次范围
## 3. 用户角色与核心场景
- 角色
- 场景
- 任务目标
## 4. 页面与模块清单
- 页面/模块名称
- 类型：页面 / 弹窗 / 抽屉 / 流程步骤 / 组件区块
- 对应目标
## 5. 页面或模块详细说明
### 5.1 <页面或模块名>
- 目标
- 进入条件 / 出现时机
- 信息架构
- 布局区块建议
- 关键字段与展示规则
- 主操作 / 次操作
- 交互规则
- 状态设计
- 校验与提示
- 权限 / 角色差异
- 响应式或平台差异
## 6. 组件与复用建议
- 可复用组件
- 相同交互模式
- 需要统一的状态样式
## 7. 文案与可访问性要求
- 关键文案
- 风险提示
- 空态 / 错误态文案
- 无障碍或可读性约束
## 8. 设计约束
- 业务约束
- 技术约束中会影响 UI 的部分
- 必须保留的信息或流程
## 9. 待确认问题
- Q1 ...
- Q2 ...
如果用户指定了自己的模板或章节名，优先遵循用户模板；没有指定时再使用上述结构。
完成后检查：
outputDoc 是否是本次唯一新增或更新的目标文档，除非用户另有要求。flowcode_design。flowcode_wiki 整理，但只有在用户明确需要时才这样做，不要默认扩大工作范围。完成后简短说明：
sourceReqPath、supportingDocs 和 outputDoc