用途：把实现类任务从用户请求一路推进到“可合并的 PR”，而不是停在本地改完代码。适合让 Codex 完成一项改动并交付到 Pull Request 的场景。
主要能力与流程：先确认范围与仓库状态，读取 AGENTS.md 等本地说明、ledger/review-feedback.md 等反馈台账，检查 git 状态、分支、远端、脚本、测试与源码结构；随后设定目标（含要实现的行为、要跑的验证、要开的 PR 与合并就绪跟进），制定最小适用的实现计划（功能、缺陷修复、重构、文档、前端、后端或 CI 修复）。实现阶段优先沿用既有模式、API 和测试，保持改动范围收敛，命令、配置、API、工作流或用户可见行为变化时更新文档。
验证与发布：先跑定向测试，再按情况跑 lint/type/build/test；UI 改动需在真实浏览器检查响应式布局与关键视觉状态。提交前检查 diff，排查缺陷、回归、缺失测试、数据丢失、安全与边界问题，再提交、推送并默认创建 ready-for-review 的 PR（除非用户明确要草稿）。
合并就绪阶段：检查 PR 状态、必需检查、CI、评审请求、机器人评论与未解决线程；收集人工、机器人、智能体的可执行反馈并逐项修复，重复该轮次直到没有未解决项。使用 pr-guardian 处理 CodeRabbit、Codex 等评审自动化提出的可执行评论；用 retrospective-codify 把可复用经验写回项目反馈台账。若反馈冲突、不准确或需扩大范围，应说明并标记阻塞，而非宣称完成。必需检查或机器人评审未完成时不得称为可合并。除用户明确要求且仓库政策允许外不合并。
组合技能：goal-manager、feature-implementation、bug-fix、refactor-safely、docs-updater、ui-imagegen-director、modern-web-guidance、Browser、Playwright、review、GitHub PR 与 CI 相关技能、pr-guardian、retrospective-codify。
最终报告应包含：目标状态、变更行为与关键文件、本地检查及结果、PR URL/分支/CI 与评审状态、PR 后修复、未解决评审线程数、未解决可执行智能体发现数、剩余阻塞与风险。
限制：未提供具体安装命令、价格或平台支持信息。