用途：在 FastMCP 仓库中把一个选定 issue 从复现推进到受控修复、兼容性审查、验证，并维持一个被监控的 Pull Request。
主要能力与流程：先阅读 AGENTS.md 与开发指南中的贡献政策，通读 issue 讨论、相关历史及各状态关联 PR，评估已有贡献后再决定是否写竞争性修复；若下一步是分配，使用 review-issue。承接既有工作时保留贡献者署名。
建立契约：把公开请求追踪到失败操作，确认是受支持行为被破坏而非仅是行为意外；实现前声明范围与兼容边界（哪些输入必须改变、哪些相邻行为必须保留、是否需要迁移）。若预期契约未定，把精确问题交给维护者。
红绿与审查：使用 python-tests，在未改动代码上复现失败并确认失败原因正确，再做最小的因果性修复；测试显式覆盖及共享该分支的相邻受支持路径，不扩大到无关标准缺口。用 review-pr 自审完整变更（含文档与依赖边界），区分必要兼容性改动与意外回归，并说明是否仍为破坏性变更；不因测试通过就推断兼容。提交前运行仓库要求的依赖同步、全量测试与静态检查，遵守分支与署名约定；必需检查失败时调查并报告证据，而非隐藏失败。
发布与跟进：在既有授权内更新已有 PR 或新开聚焦 PR，必要时用草稿状态；遵循仓库 PR 正文约定，若有 pr-body 技能也使用它；描述实际用户可见变更与迁移，而非开发日志。维护者实现社区 issue 时，提交与发布前应用贡献者致谢：读取 issue 作者 GitHub 资料确认身份，优先使用 GitHub 提供的 noreply 地址，身份不明时询问；在实现提交与 PR 描述末尾加入 Co-authored-by: Name <email>，并保留已有贡献者署名。报告问题即足够，不要求代码或根因分析；尊重退出致谢的意愿，不把机器人账号当作人类 issue 贡献者致谢。维护者通常免于补充致谢检查；维护者报告与例行 backport 保留社区署名即可，不因维护者开过原 PR 就加署名，backport 无需重新致谢审计。发布后启动 review-pr 监控；CI 完成与评审完成是两回事，要解决真实发现并报告实质兼容性决策，绿色检查不代表已解决；未获授权不得合并或标记就绪。
限制：资料未提供具体安装命令、价格、平台要求或量化效果。