메뉴
需求池管理。用户随时抛出想法/痛点，AI 负责追问、整理、合并、归档到需求池文件。用户准备开新版本时，协助从池中筛选。痛点驱动，不做提前排期。
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 | backlog-manager |
| description | 需求池管理。用户随时抛出想法/痛点，AI 负责追问、整理、合并、归档到需求池文件。用户准备开新版本时，协助从池中筛选。痛点驱动，不做提前排期。 |
用户随时会抛出产品想法、使用痛点、功能需求。AI 负责将这些零散输入整理成结构化的需求池， 并在用户准备启动新版本时协助筛选。需求池是一个持续维护的文件，不是一次性产出。
位置：docs/需求池.md
如果文件已存在，在现有内容上更新。如果不存在，按以下模板创建。
# 需求池
> 随手记，随时加，隔段时间过一遍。
>
> 状态说明：
> - **可以做了** — 痛点清晰，知道要做成什么样，随时能进设计/PRD
> - **需要想想** — 方向有了，细节没展开，需要调研或讨论
> - **先放着** — 记着就行，现在不花精力想
> - **已完成** — 做完了，标版本号归档
---
## 总览
| # | 需求 | 状态 | 依赖 | 备注 |
|---|------|------|------|------|
| 1 | xxx | 可以做了 | 无 | xxx |
---
## 可以做了
### 需求名称
- 痛点：xxx
- 方案：xxx
- 备注：xxx
---
## 需要想想
### 需求名称
- 方向：xxx
- 依赖：xxx
- 待展开：xxx
---
## 先放着
### 需求名称
- 想法：xxx
- 备注：xxx
---
## 已完成
### 需求名称（V0.xx）
- 完成时间：yyyy-mm-dd
- 简述：xxx
每个条目根据所在分区使用不同字段：
| 分区 | 必填字段 | 可选字段 |
|---|---|---|
| 可以做了 | 痛点、方案 | 备注 |
| 需要想想 | 方向 | 依赖、待展开 |
| 先放着 | 想法 | 依赖、备注 |
| 已完成 | 完成时间、简述 | — |
总览表每个条目必须有：编号、需求名称、状态、依赖、备注。
用户说了一个想法或痛点后，主动追问：
整理成一句话描述，向用户确认："我理解的是 xxx，对吗？"
禁止：
禁止：
确认后更新 docs/需求池.md：
格式要求：
当用户说"整理一下需求池"或"看看需求池"时：
禁止：
当用户说"下一个版本做什么"或"挑一个来做"时：
| 标准 | 问题 |
|---|---|
| 频率 | 你多久被这个问题卡一次？ |
| 可绕过性 | 不做的话手动能搞定吗？多麻烦？ |
| ROI | 做完之后日常能省多少事？ |
禁止：
当用户说"xxx 做完了"或"标记完成"时：
| 时机 | 问什么 |
|---|---|
| 第 1 步 | 痛点、频率、现在怎么绕 |
| 第 2 步 | 合并是否合理、状态归类是否正确 |
| 第 4 步 | 每条变更建议是否同意 |
| 第 5 步 | 从候选里选哪个 |
| 事项 | 直接做 |
|---|---|
| 文件格式 | 按模板写，不用问 |
| 编号分配 | 自动递增 |
| 总览表同步 | 改了详情就同步总览表 |
| 没变化的条目 | 整理时直接跳过 |