用途
该技能用于对 GitHub Issue 或通过文字报告的问题进行系统性排查（triage），目标是让用户先确认问题是否真实存在、问题表现是什么、修复会带来哪些变化，并有一套可运行的 POC 作为依据，再由用户决定是否进行完整修复。它明确不执行完整修复，结束于第 5 步并等待用户回答。
主要能力
- 确认真实性与是否属于设计行为：完整阅读 Issue（包括评论），尝试用最小方式复现；通过 git log -S、git log -L、git blame 查看相关决策，检索相关 PR 与重复 Issue；如果安装了 Hindsight 插件，可搜索知识页面或在需要了解原因时运行 reflect，但需将结果与代码对照。
- 在无意义时停止：若问题不真实、已修复、重复、属于设计行为、本地环境问题或无需更改，则用证据（提交、PR、Issue、代码行）向用户说明，并准备一段简短友善的关闭评论，但必须在用户同意后才发布或关闭。
- 探索代码：找出涉及代码的所有调用方与可能触发同一问题的路径，寻找可复用的相似代码、辅助函数、类型与模式，阅读 .claude/skills/code-review/SKILL.md 使 POC 符合仓库规则，并查看相关测试及其断言方式。
- 构建并验证 POC 修复：在 origin/main 的新分支（triage/<issue-number-or-short-slug>）上工作。不使用临时绕过方案，POC 必须是长期正确的修复。验证包括：复现用例在修改前失败、修改后通过；附近测试仍通过；修复整个问题而非单一症状；性能问题需用相同或更小规模复现并测量修改前后数据（使用仓库性能工具或小脚本）；UI 变更需启动 API 与控制面，使用空闲端口与独立的 pg0 实例，记录 PID 与实例名，准备数据并尽量在浏览器中打开，提供链接。只停止自己启动的服务，只删除自己创建的 pg0 实例，用户查看期间保持 UI 运行，结束后停止一切。
- 解释并询问：用行为语言向用户说明问题现状、后果、POC 改了什么以及为何能消除根因、行为变化、证据（复现前后对比、测试结果、性能数据、UI 链接）以及完整修复仍需要什么（测试、文档、迁移、客户端重新生成、其他调用点）。然后询问是否进行完整修复，在用户回答前不开始。
适用场景
适用于维护者或开发者需要快速判断一个 GitHub Issue 是否值得修复、是否属于设计行为、如何以最合理的方式修复，并希望先看到可运行证据再决定是否投入完整修复的场景。也适用于性能问题或 UI 问题的初步验证。
限制
该技能不执行完整修复，不自动发布评论或关闭 Issue。POC 必须是长期正确修复而非临时绕过方案；若无法复现必须明确说明尝试过什么。性能问题必须有修改前后数据，否则不能制定计划。启动服务时必须避免影响共享资源。资料未提供该技能在具体仓库之外的通用性说明、安装方式或收费信息。