用途：在评审者留下行内评论、且修复已推送到 PR 之后，按条回应评审意见。它明确不负责发布初始评审——发布新评审或复审 diff 属于 pr-reviewer 技能的职责，pr-fixer 只负责修复落地后回复各评论线程。
主要能力与工作流：一是分诊，先读完所有评论，为每条写一句简短的待改说明，形成工作清单；二是逐条处理，每条评论单独修复、测试、提交，不跨评论批量提交；三是回复，每条修复提交后，在该评论线程回复提交哈希与简要说明。回复格式分两种：已修复写“Fixed in <commit-hash>”并附非显而易见处的更改说明；延后处理写“Not addressed in this PR. Tracked in <issue-url>.”并附一句延后原因，且必须先创建 GitHub issue 再粘贴 URL，否则视为不完整。
限制：绝不自行解决评论线程。解决线程是人工评审者的工作，回复后即停止，不得点击“Resolve conversation”或调用任何将线程标记为已解决的 API，由人决定评论是否已满足。
评论类型与修复方式：架构类（模式对齐、关注点分离、模块边界、文件组织）应按既有模式重构代码，而非仅让其能跑；安全类（环境变量处理、认证流程、输入校验、令牌/凭据存储、敏感数据暴露）必须套用正确的安全模式，不可选做；性能类（低效算法、冗余计算、缓存机会、包体积、查询优化）需评估取舍，在当前规模下成立则实现，否则建 issue 延后；质量类（可读性、命名约定、错误处理、代码重复、测试覆盖、文档）应沿用代码库其他地方的约定，不引入新风格。
渐进改进：若开发者纠正了本应由此技能预防的行为，建议对该技能提出具体修订，以防同类问题再次出现。其余细节资料暂未提供。