用途：针对 GitHub issue 端到端解决，或以证据说明无需实现。会先获取 issue（含评论与标签），确认其为开放、可实施且非 PR、重复、阻塞或被拒项，再读取项目说明、贡献指南、Definition of Ready 与 Definition of Done、相关领域技能、真实项目命令、受影响代码路径、测试与复现步骤后决策。
主要能力：始终执行并记录网络检索以取得当前证据，优先官方与一手来源，并与检出仓库版本核对；非自动模式下需要注册的 grilling 与 render-html 技能及 Python 3，否则停止。会构建单一中立的证据包，先声明比较标准，再派生 2 至 4 个真正不同的可行选项，对每个选项做等效的决策相关验证（UI/UX 差异展示实际体验，架构或流程差异展示相关流程，交互或技术主张可用临时原型或测量）。原型仅在本地、可丢弃，不外发；只有用户明确同意才保留。
使用方式：非自动模式先用 render-html 生成临时交互式影响报告，包含证据、标准、选项影响、优缺点、评分、不确定性与可复制讨论提示，再用 grilling 逐一决策并等待用户选择；移除临时报告后创建分支或工作树，先过 git-workflow 同步门禁再编辑。实施最小完整改动并更新测试与文档；UI/UX 需渲染各受影响状态、采集前后对比证据并检查可访问性、响应式、主题与设计系统一致性。每次代码或测试改动要重复 /code-review fix-all 与黑盒测试，直到同一份未变实现上两者均通过，再跑项目门禁并用 /create-pr，PR 中带 Closes #<issue>。
适用场景：需要按 issue 要求完成实现、验证与提交流程的仓库维护工作。
限制：自动模式仅在原始提示明确要求时启用，且跳过交互报告与 grilling，但不豁免其他门禁；涉及产品、架构、安全、范围或愿景的实质决策会关闭自动模式。若复现失败需区分已修复且有覆盖、已修复但缺回归测试、同根因的兄弟路径仍受影响三种情形。若 /code-review 或 /test-against-spec 不可用，可手动执行同等的有界审查与黑盒测试。门禁失败若改动实现，需回到代码审查步骤；行为在现有环境无法验证时应停止并询问，除非用户明确接受限制或要求草稿 PR。文档未提供具体收费、价格、平台与安装命令信息，暂未提供。