用途
pr-comment-resolver 用于解决单个 PR（Pull Request）审查线程。它接收线程 ID、文件路径、行号以及完整的评论文本，核心任务是评估反馈是否有效、在有效时实施修复，并返回结构化摘要。该技能由父级流程生成（spawned by the parent），本身不直接面向最终用户。
主要能力
该技能围绕一套评估准则（Evaluation Rubric）对反馈进行分类和处理：
- 判断反馈是问题/讨论还是变更请求。若能从代码和上下文自信回答，则判定为 replied；若答案依赖无法确定的产品/业务决策，则判定为 needs-human。
- 判断关注点是否有效：审查者描述的问题是否真实存在于代码中。若不存在，判定为 not-addressing。
- 判断是否仍然相关：该位置的代码自审查以来是否已变更。若已变更，判定为 not-addressing。
- 判断修复是否能改进代码：能则判定为 fixed（或采用更优方案时判定为 fixed-differently）；不确定时默认修复。
默认倾向是修复。跳过修复的门槛是“审查者对代码的判断在事实上是错误的”，而非“优先级低”。
需要升级（verdict: needs-human）的情况包括：影响其他系统的架构变更、安全敏感决策、模糊的业务逻辑，或相互冲突的审查反馈。这种情况应当很少见。
使用方式
工作流程如下：
- 读取所引用文件和行号的代码。对于审查线程，文件路径和行号会直接提供；对于 PR 评论和审查正文（无文件/行号上下文），从评论文本和 PR diff 中识别相关文件。
- 使用上述准则评估有效性。
- 若需修复：实施变更，保持聚焦，只处理反馈内容，不重构周边代码，并验证变更不会破坏直接逻辑。
- 撰写供父级发布的回复文本。引用被处理的具体句子或段落，而非整条长评论。
回复文本格式按判定类型区分：
- fixed：引用相关部分，说明“Addressed: [修复简述]”。
- fixed-differently：引用相关部分，说明“Addressed differently: [替代做法及原因]”。
- replied（问题/讨论）：引用相关部分，给出直接回答或设计决策解释。
- not-addressing：引用相关部分，说明“Not addressing: [带证据的原因，例如‘第 85 行已有空值检查’]”。
- needs-human：在升级前完成调查工作，不要以“这很复杂”推脱。用户应能在 30 秒内读完分析并做出决定。
reply_text 会以用户身份发布到 PR 线程，应自然表达，避免 AI 套话（如“Flagging for human review”）。decision_context 返回给父级用于向用户展示，包含：审查者说了什么、发现了什么、为何需要用户决策、可选项及其权衡、以及个人倾向。
最终输出为结构化摘要，包含字段：verdict、feedback_id、feedback_type、reply_text、files_changed、reason，以及仅在 needs-human 时提供的 decision_context。
适用场景
适用于自动化处理代码审查反馈，尤其是需要逐条评估 PR 审查线程、实施修复并生成回复的场景。由父级流程调用，适合集成到代码审查自动化工作流中。
限制
- 仅处理单个 PR 审查线程，不处理相邻问题，除非反馈明确引用。
- 行动前必须阅读代码，不预设审查者正确或错误。
- 若审查者建议可行但存在更优方案，采用更优方案并在回复中解释原因。
- 需与现有代码库风格和模式保持一致。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。