メニュー
GitHub Issue 处理协作流程。当用户收到 issue 需要分析和回复时使用。通过"诊断 → 定性 → 决策 → 回复"四步法，从一个 issue 产出准确的根因分析和得体的用户回复，避免误判问题类型或回复不专业。
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 | issue-triage |
| description | GitHub Issue 处理协作流程。当用户收到 issue 需要分析和回复时使用。通过"诊断 → 定性 → 决策 → 回复"四步法，从一个 issue 产出准确的根因分析和得体的用户回复，避免误判问题类型或回复不专业。 |
用户收到了一个 GitHub Issue（bug 报告、疑问、feature request），需要 AI 协助分析问题、判断是否要做、起草回复。AI 全程主导推进，用户只在关键节点做判断。
目标： 拿到 issue 的完整信息。
方法：
gh issue view 或 WebFetch 获取 issue 详情输出： 向用户简要转述 issue 内容，确认理解无误。
禁止： 只看标题就开始分析。必须读完 issue 全文。
目标： 在代码中找到根因。
方法：
输出： 向用户展示：
禁止：
目标： 判断这个 issue 属于哪种类型。
| 类型 | 判断标准 | 应对策略 |
|---|---|---|
| Bug | 在产品设计范围内，行为不符合预期 | 排期修复 |
| 架构限制 | 用户场景超出产品的设计前提 | 解释现状，评估是否值得扩展 |
| Feature Request | 产品本身没问题，用户想要新能力 | 评估成本和优先级 |
| 使用问题 | 用户操作方式不对，但产品可以做得更友好 | 回复指引，考虑优化体验 |
关键判断： 区分"该做但做错了"（bug）和"没打算做"（架构限制/feature）。
输出： 向用户说明定性结论和理由，等用户确认后再往下走。
目标： 基于根因和定性，给出做/不做的建议。
| 改动范围 | 有测试条件 | 用户可绕过 | 建议 |
|---|---|---|---|
| 小（几行） | 有 | — | 直接修 |
| 中（一个模块） | 有 | — | 排期做 |
| 大（新模块/重构） | 有 | 否 | 评估后排期 |
| 大（新模块/重构） | 没有 | 是 | 记下需求，暂不做 |
| 任意 | 没有 | 是 | 告知绕过方案，需求记下 |
输出： 向用户说明建议和理由。如果建议不做，要量化成本（改几个文件、涉及哪些模块、为什么没法测）。
等用户确认决策后，再进入回复环节。
目标： 写一条专业、得体、有信息量的 issue 回复。
Hi @{用户名}，感谢反馈！
**1. 功能定位**
{这个功能是为什么场景设计的，为什么当前不支持用户的场景}
**2. 对你的实际影响**
{用户现在能不能绕过，怎么绕过，核心功能是否受影响}
**3. 关于{用户期望的能力}**
{成本说明 + 后续计划}
输出： 回复草稿，等用户确认后发布。
禁止：
用户确认回复内容后：
gh issue comment 发布评论| 步骤 | 确认什么 |
|---|---|
| 第 1 步 | "issue 内容我理解的对吗？" |
| 第 3 步 | "这个定性你认同吗？" |
| 第 4 步 | "这个决策你同意吗？" |
| 第 5 步 | "回复内容可以发吗？" |
| 事项 | 直接做 |
|---|---|
| 代码怎么查 | AI 自己追链路 |
| 根因怎么分析 | AI 自己判断 |
| 成本怎么量化 | AI 自己评估 |