Feedback 是一个面向 GitHub Pull Request 评审流程的只读技能（skill）。它的用途不是重新做一次代码评审，而是消费 PR 上已经存在的评审评论——包括 Copilot 和人类评审者——并判断哪些值得修、哪些不值得。每条评论都会先与当前代码核对，再给出结论。该技能不会回复讨论串、解决对话或发布任何内容，输出仅为用户的决策辅助。与 code-review 技能不同：后者生成新的发现，本技能评估已有评审评论。
主要能力与流程：
- 使用 gh 获取评论：拉取 PR 的评审评论（默认当前分支的 PR），覆盖行内讨论串评论与顶层评审摘要，来源包括 Copilot 和人类评审者。只保留未解决的讨论串——解决状态存在于 GraphQL 的 reviewThreads 字段（isResolved）中，而非 REST 的 pulls/comments，因此需要过滤已解决或过时噪音时应使用 gh api graphql。为每条记录作者、路径、行号和正文。若无未解决评论，则报告该情况并停止。
- 对照当前代码核实：读取 path:line 处的文件，确认评论是否仍然适用。评审者（尤其是机器人）常对过期 diff 发表评论并忽略周边上下文。标注 outdated: true 的讨论串默认倾向 Skip，除非该担忧在当前代码中仍成立。完成标准是每条评论都已对照实际代码检查，而非仅凭文字判断。
- 按标准分类：每条结论都附一句基于第二步所见内容的理由。
- 输出分诊表：按 Address 优先分组。完成标准是每条获取到的评论都出现在表中并带有结论与理由。
- 提出修复：询问是否实现 Address 项。若用户同意，则以 tdd（测试优先）调用 Skill 工具处理它们。不会自动实现；不触碰 Skip/Optional/Discuss 项。
判定标准：
- Address：对照当前代码核实为真实缺陷、风险、正确性缺口或明显有效的改进。
- Skip：错误、误报、已过时（代码已变）、与既有代码库约定矛盾，或超出本 PR 范围。理由必须引用证据，而非仅作断言。
- Optional：主观/风格/偏好，无正确性影响，由用户决定。
- Discuss：有效但需要用户单独决策的担忧（产品权衡、破坏性变更、架构方向）。
输出格式为 Markdown 分诊表：标题为 Triage: PR #<n> — <title>（<count> unresolved），并按 Address、Optional、Discuss、Skip 分组；每条列出 path:line、@author、评论要点和理由。
错误处理：gh pr view 失败时运行 gh auth status；若不在 PR 分支上，询问 PR 编号。评论所属文件在 PR 中被删除或重命名时，注明并倾向 Skip（担忧可能已转移）。Copilot 评论引用 diff 之外的行时，视为低信号，需先核实周边代码再决定是否采信。
适用场景：开发者收到大量 PR 评审意见（尤其混有 Copilot 自动评论）时，用于快速甄别哪些评论应处理、哪些可忽略，并决定是否以测试优先方式实现。限制：仅支持 GitHub PR；依赖 gh CLI 与认证；只读，不参与讨论；对无法仅凭代码判断的产品或架构问题只归入 Discuss，不代为决策。