Menu
GitHub Issue 处理协作流程。当用户收到 issue 需要分析和回复时使用。通过"诊断 → 定性 → 决策 → 回复"四步法，从一个 issue 产出准确的根因分析和得体的用户回复，避免误判问题类型或回复不专业。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 自己评估 |