القائمة
新功能设计探索流程。当用户有模糊想法要做新功能/新模块时使用。通过"需求收敛 → 技术调研 → ASCII 批量探索 → HTML 设计稿 → 全状态覆盖 → 需求总结"的结构化流程，从模糊想法产出可交付的设计参考文档，作为 PRD 阶段的输入。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Issue 池全生命周期管理（开发范式 v1 规划段）：记 issue 入池+关联检查、合并同源需求、讨论拆解（引导讲出真需求）、转成可开工 task 或滚动 plan、拆不动就 pending。复杂 plan 的框架计划正文流程已内置（原 plan-report 并入 references/plan-writing.md）。当用户说"记个 issue""新增/汇总 issue""拆 issue / 拆解
把用户的模糊诉求、粗糙 goal、handoff prompt 或任务想法收敛成 AI 可以自主执行且可验收的 goal。用于用户要求写 goal、优化 goal、制定交给 AI/subagent/Codex 执行的目标、明确 scope/non-goals/success criteria/verification/stop conditions，或需要把“今天做完、尽量优化、帮我研究并执行”等不清晰请求变成可执行任务契约时。
帮助梳理一份"框架计划报告"(项目 v1.0 计划、版本路线、阶段方案等)。通过"摸现实 → 定文档类型 → 搭骨架 → 填内容 → 统一结构 → 语言精修 → 自检" 7 步引导,产出"讲为什么做 / 做到什么程度算完 / 分几步走"的框架计划,而不是功能清单或技术方案。当用户说"写计划报告"、"项目计划"、"框架计划"、"v1.0 计划"、"版本路线"、"阶段方案"、"plan-report"、"/plan-report"时触发。
陪伴型 AI 人设生成与优化流程。当用户想给 Hermes Agent（或任意 AI 陪伴角色）做一个"有感情、聊久不掉、像真人"的人设时使用。通过"定调子 → 名字 → 外形 → 性格 → 背景 → 关系 → 说话节奏 → 生成 SOUL.md → 迭代"的结构化对话，从一句模糊想法（如"我想要个JK女友""年上男友""高冷御姐"）产出可直接贴进 Hermes SOUL.md 的第一人称人设文本。支持女友/男友/各种气质的陪伴角色，并让用户选择"一句一句发"还是"整段说"的输出风格。当用户说"做个人设/捏个AI女友男友/给Hermes弄个角色/优化人设/换个人设"时触发。
PRD + 可执行测试用例双文档一体化协作。与用户共同写并迭代。理解需求后自主读代码再写；故事驱动 + 分阶段单点确认；每个 PRD 产出 PRD-MD 与 测试用例-MD（给 AI 的事实源）+ 两份套模板的 review HTML（给人查阅，与 MD 严格 1:1）。触发：梳理/撰写/完善 PRD、需求文档、用户故事、验收标准、测试用例、测试基准、测试方案。
系统化学习材料生成器。给一个新领域/技术/概念，AI 自主调研、搭体系、产出 HTML 学习材料（含骨架/案例/工程化/争议+盲区）。当用户说"我要学 X / 帮我系统拆解 X / 我想吃透 X 这个领域 / 给我整理 X 的全貌 / 深度调研 X 给我系统讲讲 / 把 X 搞透"时触发。不适用于"X 行不行/为什么 Y"（用 long-research）、"X 有哪些好玩案例"（用 case-radar 给散点）、"把这堆素材整理成 HTML"（用 readable-output 处理已有素材）、文章写作（用 writing-assistant）、设计稿（用 design-exploration）。
| name | design-exploration |
| description | 新功能设计探索流程。当用户有模糊想法要做新功能/新模块时使用。通过"需求收敛 → 技术调研 → ASCII 批量探索 → HTML 设计稿 → 全状态覆盖 → 需求总结"的结构化流程，从模糊想法产出可交付的设计参考文档，作为 PRD 阶段的输入。 |
用户有一个模糊的想法，想做一个新功能或新模块，但还没想清楚具体要什么。通过结构化的探索流程，帮助用户从模糊想法收敛到明确的设计方案，并产出完整的设计参考文档。
每次探索产出 3 个文件，归档到 设计/v{版本号}-{模块名}/ 目录下：
| 文件 | 内容 | 用途 |
|---|---|---|
需求总结.md | 背景、目标、功能范围、关键决策、技术约束 | PRD 阶段的输入，讲清楚"为什么做、做什么" |
{模块名}-设计稿.html | 主界面 HTML mockup | PRD + 前端开发的视觉参考 |
{模块名}-全状态设计参考.html | 所有页面状态、Toast、边界情况、交互规则表 | 前端开发直接对照实现 |
版本号和模块名由用户决定，必须问用户确认。
用户说了模糊想法后，主动追问：
整理成结构化的需求共识：
做什么：
- xxx
- xxx
不做什么：
- xxx
载体：独立应用 / 已有应用的新 Tab / 插件 / ...
禁止：用户说了一句话就开始出图。必须先对齐需求边界。
判断是否需要调研：如果功能涉及外部数据（配置文件、API、第三方系统、文件格式），必须先调研技术约束。如果是纯 UI 功能不涉及外部依赖，跳过。
调研内容：
调研结果会直接影响设计方案（比如发现两个工具配置格式不同，决定了界面需要展示"类型"列）。
禁止：跳过调研直接画图，画出来发现技术上实现不了。
一次出 5-8 个不同思路的 ASCII 布局方案，每个方案包含：
方案 A：卡片列表 + 工具勾选
┌──────────────────────────────────┐
│ ┌────────────────────────────┐ │
│ │ pencil [✓] CC [✓] CX│ │
│ └────────────────────────────┘ │
└──────────────────────────────────┘
方案 B：表格视图，一行一个
┌──────────────────────────────────┐
│ 名称 类型 CC CX │
│ pencil stdio [✓] [✓] │
│ github http [✓] [✓] │
└──────────────────────────────────┘
用户可以：
禁止：
问用户以下问题：
有没有已有的设计规范？（如 design-system.html）
有没有要参考的已有页面？（外框、导航结构）
载体形式？
禁止：没问就默认使用某个设计规范。
基于选定方案 + 确认的设计风格，输出 HTML mockup：
输出后让用户浏览器打开查看，根据反馈微调。微调是具体的小修改（间距、配色、文案），直接执行，不需要重新走方案选择。
产出一个完整的全状态设计参考 HTML，固定包含以下内容：
| 状态 | 说明 |
|---|---|
| 正常态 | 有数据的标准展示 |
| 加载态 | 数据加载中（spinner + 禁用交互） |
| 空态 | 没有数据，引导文案 |
| 搜索/筛选无结果 | 有数据但当前条件无匹配 |
| 错误态 | 数据加载失败、文件不存在、格式错误等（按场景拆多个） |
| 部分可用 | 部分数据源可用、部分失败 |
表格格式，列定义：
| 触发 | 用户操作 | 系统行为 | 反馈 |
|---|---|---|---|
| 用户/系统/异常 | 具体操作 | 详细的系统处理步骤 | Toast/状态变化/界面更新 |
覆盖所有用户操作和系统行为的完整映射，前端开发直接对照实现。
禁止：只做正常态就结束。全状态覆盖是本流程的核心交付物。
按模板（templates/需求总结-模板.md）生成需求总结文档。
将对话中确认的所有决策提取出来，写入"关键决策"部分。这些决策往往散落在对话各处，必须主动收集整理，不能遗漏。
三个文件归档到 设计/v{版本号}-{模块名}/ 目录下。版本号和模块名问用户确认。
设计/v0.11-MCP管理/
├── 需求总结.md
├── mcp-manager-设计稿.html
└── mcp-manager-全状态设计参考.html
| 时机 | 问什么 |
|---|---|
| 第 1 步 | 痛点、场景、边界（做什么/不做什么） |
| 第 3 步 | 选哪个方案 |
| 第 4 步 | 有无设计规范、参考页面、载体形式 |
| 第 5 步 | mockup 效果是否满意，有无微调 |
| 第 6 步 | 全状态覆盖有无遗漏的场景 |
| 第 7 步 | 版本号和模块名 |
| 事项 | 直接做 |
|---|---|
| 全状态要不要覆盖 | 必须覆盖，不用问 |
| 交互规则表要不要写 | 必须写，不用问 |
| 需求总结要不要输出 | 必须输出，不用问 |
| Toast 文案 | 先给出建议，用户不满意再调 |