用途：用于编写 agent-relay 工作流，使功能在合并前完成端到端验证，解决“代码写完、类型通过、能构建”到“确实可用”之间的差距。目标是每个通过此类工作流合并的功能都是经过测试、验证且已知可用的。
主要能力与原则：在工作流内部以确定性步骤运行测试，流程为 implement → 写测试 → 运行测试 → 修复失败 → 重跑 → 构建检查 → 回归检查 → 提交。80到100工作流不应因测试、类型检查、lint、schema 或 E2E 门禁变红就终止，而应捕获红输出、交给修复负责人修复并重跑。若团队耗尽修复预算或遇到外部阻塞（如缺少凭据、仓库错误、工作树不安全），应写出 BLOCKED_NO_COMMIT 产物并结束，不提交或开 PR，而不是让工作流崩溃。
门禁写法：run-* 使用确定性命令、captureOutput: true、failOnError: false；fix-* 为 agent 步骤，读取 {{steps.run-.output}} 并本地修复重跑直至通过；verify- 为确定性重跑；commit-if-green 重新运行完整验收命令，仅在全部退出码为零时提交，否则写 BLOCKED_NO_COMMIT。资料提到 AgentWorkforce/relay#827 增加了修复感知可靠性（.reliable() / .repairable() 与修复感知重试模式），可用时优先使用这些预设，但仍需为需要领域修复的门禁显式建模修复负责人。
关键约束：可修复门禁须在关键路径上，避免长期交互 agent 步骤成为首个门禁的硬依赖，以免传输故障先于修复循环发生。建议实现 agent 作为建议性生产者，将确定性 reconcile 步骤放在关键路径，读取 git status --short -- <paths>、必需文件与 diff 统计，再由 repair-implementation-reconcile 补全，之后才进入发现、类型检查、E2E 与最终验收。
审查结构：高风险工作流应包含类人审查。将独立范围拆为 2-3 个 agent 小队，每队含实现者、影子审查者，可选验证/测试负责人；实现者在外部审查前写自反思产物；新的自审查 agent 读取实际文件、AGENTS.md / CLAUDE.md 与本地约定并写盘；实现者修复有效发现后重跑确定性门禁。审查深度分 Light、Standard、Deep：Light 需 review-claude → fix-loop，并以 post-fix-validation 作为最终审查门禁；Standard 增加 final-review-claude → final-fix-claude；Deep 在 Standard 基础上增加 review-codex → fix-loop-codex → final-review-codex → final-fix-codex。只有审查路径、final-review-pass、最终确定性验收、受限 diff/回归门禁全绿，才允许提交或开 PR，否则写 BLOCKED_NO_COMMIT 并附证据。
测试模式：测试-修复-重跑四步为运行测试（允许失败）、修复 agent、确定性重跑、再次修复。数据库测试可用 PGlite 内存 Postgres，安装命令为 npm install --save-dev @electric-sql/pglite，注意 PGlite 不运行 Drizzle 迁移，需手写与 schema 匹配的 DDL。每次 agent 编辑后应加确定性 verify 门禁，检查 git diff 与 grep 文件内容。回归测试运行 npm run orchestrator:test 或 npm test，修复现有测试破坏。资料中完整工作流模板较长，此处不展开。
限制：技能未说明支持平台、收费、价格或效果保证；具体命令与模板来自资料，缺失信息暂未提供。