메뉴
新功能设计探索流程。当用户有模糊想法要做新功能/新模块时使用。通过"需求收敛 → 技术调研 → ASCII 批量探索 → HTML 设计稿 → 全状态覆盖 → 需求总结"的结构化流程，从模糊想法产出可交付的设计参考文档，作为 PRD 阶段的输入。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| 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 文案 | 先给出建议，用户不满意再调 |
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）。