用途：用于编写 agent-relay 工作流，使功能在合并前完成端到端验证，而非仅停留在“代码可编译”的约 80% 状态。核心是让工作流自身运行确定性测试并修复失败，直到测试全绿才提交。
主要能力与模式：
- 测试-修复-重跑：实现→写测试→运行测试→修复失败→重跑→构建检查→回归检查→提交。
- 修复优先于失败：验证门用 captureOutput: true 与 failOnError: false 捕获红色输出，交给修复型 agent 步骤读取 {{steps.run-*.output}} 修复并重跑；修复预算耗尽或遇外部阻塞时输出 BLOCKED_NO_COMMIT 并结束，不提交或开 PR。
- 可修复门保持在关键路径：让发现、类型检查、E2E 与最终验收依赖确定性的 reconcile/repair 路径，而非长期运行 agent 步骤。
- 小队审查：2-3 个实现小队，含实现者、影子审查者与可选验证负责人；写自我反思工件，做全新视角自审，最后顺序执行 Claude 与 Codex 的审查/修复循环。
- PGlite 内存 Postgres：npm install --save-dev @electric-sql/pglite，使用 DDL 建表并配合 drizzle-orm/pglite；注意 PGlite 不运行 Drizzle 迁移。
- 每次编辑后加确定性验证门，检查 git diff 与文件内容；编辑门需覆盖新文件。
- 新测试通过后运行既有测试套件捕获回归。
使用方式（示例）：在 @relayflows/core 的 workflow 中配置 pattern('dag')、repairable()、agent 步骤与 deterministic 步骤，测试命令如 npx tsx --test tests/my-feature.test.ts、构建检查 npx tsc --noEmit。
适用场景：交付物需生产就绪、功能涉及本地可测的数据库/API/基础设施、以及“能编译”不足以证明正确性的工作流。
限制：资料未提供该技能的具体安装命令、收费、价格、平台或效果数据；是否可用 .reliable() / .repairable() 取决于 SDK 版本，资料提示优先使用但显式修复所有者仍需建模。