用途
workflow-green-repo 用于把整个代码仓库带到经过验证的绿色基线：从干净状态出发，让每一项已配置的健康门禁（health gate）全部通过。这是一次范围广泛、且已获授权的清理工作——在这里，修复与当前工作无关的既有失败正是目标本身，而不是范围蔓延。
“绿色”的定义是：从零开始全新运行每一项门禁后全部通过，而不是仅凭你碰巧看到的那些失败来判断。因此流程要求：先枚举，再把工作清单外化，批量修复根因，反复重跑直到归零。
主要能力
- 发现并确认仓库真实的门禁命令，而不是凭假设推断。
- 捕获基线失败，区分真实回归与偶发不稳定（flake）。
- 将失败清单持久化到
.cursor/green-repo-state.md，作为跨上下文压缩的事实来源。 - 按批次修复根因，禁止用跳过、收窄断言、忽略错误等方式伪造通过。
- 从零重新运行所有门禁，证明绿色，并输出结构化报告。
使用方式
自由度说明
本技能为 MIXED（混合）自由度：每个失败的根因分析为 HIGH 自由度；门禁发现、工作清单、以及“不跳过/不静默”为 LOW 自由度——必须严格照做。
推理要点
- Authorize（授权）——用户明确要求整个仓库变绿。
- Enumerate（枚举）——使用真实命令与基线失败，而非假设。
- Fix-root（修根因）——不跳过、不收窄、不忽略。
- Prove（证明）——从零全新运行每一项门禁。
示例
- 授权：用户说“让这个仓库的 CI 通过”。
- 枚举：
pnpm typecheck在 lib/billing 有 14 个错误；pnpm test有 3 个日期时区相关失败。 - 修根因：恢复上次重构丢失的 Invoice 判别字段；修复测试时钟中的时区，而不是
.skip整个测试套件。 - 证明：从零重跑 typecheck/lint/test/build → 干净；状态文件中零个未解决失败。
报告前自检
- 已授权——这不是对无关债务的静默重写。
- 无假绿——没有
.skip、@ts-ignore或弱化断言。 - 全新证明——绿色是一次完整新运行，而非上一批次的结果。
- 归属正确——某个计划的遗留 → complete-everything；单一模式 → burndown-full；ratchet 作弊 → audit-gate-logic。
何时不要使用（LOW 自由度——不可跳过）
- 用户要求完成某一个计划或功能 → 使用 complete-everything。
- 改动是跨文件的一个可搜索模式 → 使用 burndown-full。
- 没有明确授权触碰既有债务 → 先确认范围；不要静默重写无关代码。
Phase 0 — 确认授权并发现门禁（LOW 自由度——严格照做）
确认用户希望整个仓库变绿，包括早于其工作存在的债务。如果范围更窄，转用 complete-everything。
发现真实门禁命令——绝不假设。阅读 package.json scripts、Makefile、justfile、CI workflows（.github/workflows/*）、AGENTS.md、CLAUDE.md 和 README。识别以下各项的确切命令：typecheck、lint/format、单元/集成测试、e2e（如有）、build。
记录每项门禁所需范围（整个仓库 vs. monorepo 中的按包）以及任何环境前置条件（服务、环境变量、fixtures）。
捕获基线：每项门禁运行一次并记录失败输出。这是工作清单的来源，也能把真实回归与偶发不稳定区分开。
Phase 1 — 枚举完整失败工作清单（LOW 自由度——严格照做）
写入 .cursor/green-repo-state.md 作为持久事实来源，包含：门禁命令、基线捕获日期、失败清单（typecheck/lint/test/build 各条目）、偶发/环境相关（隔离，不假修）、修复过程中发现的（追加后修复）、有意例外（逐条说明理由——需人工签字）、证据。
陈述总数：“N 个失败门禁，跨 M 个区域。全部驱动至绿色。”
将工作清单镜像到原生任务列表以便 UI 可见；上下文压缩后以状态文件为准。
Phase 2 — 批量修复根因（HIGH 自由度）
按小批次处理清单（一个门禁区域或 5–10 个相关失败）：
- 编辑前先阅读失败代码及其意图，理解为何失败——不要用模式匹配来静默。
- 修复根因。禁止：删除/
.skip/.only测试、收窄断言使其无法失败、用@ts-ignore/eslint-disable/any隐藏真实类型错误、吞掉异常的宽泛 try/catch、掩盖回归的全量快照更新。 - 仅当输出变化正确且有意时才可更新快照或 golden 文件——并说明原因。
- 每批次后立即在状态文件中勾选条目。
- 将新浮现的失败追加到“修复过程中发现的”并在本次运行中关闭。
- 若某失败确实偶发或需要你缺少的真实环境，将其移入隔离/例外区并写明精确原因——绝不伪造通过。真实环境阻塞是唯一的停止条件。
- 外科手术式编辑：只改导致失败的部分，而非周边文件。为固定修复或匹配仓库既有做法而新增的测试才保留；用于复现的临时脚本不留在仓库中。
- 批次之间不要暂停询问“继续吗？”，也不要因上下文变长就收尾——这种规模的运行会发生压缩，状态文件会携带工作清单跨越压缩。持续进行直到清单为空；重读状态文件而非依赖记忆。
Phase 3 — 从零证明绿色（LOW 自由度——严格照做）
在每项已配置门禁于全新运行中通过之前，不要报告绿色：
- Typecheck（整个配置范围）→ 干净。
- Lint/format → 干净。
- 单元/集成测试 → 全部通过；隔离项明确列出。
- E2E（如已配置）→ 通过。
- Build → 成功。
- 状态文件：除有理由的例外外，零个未勾选失败。
若仓库有 CI，注明相同门禁是否在那里运行、是否有环境特定项（以便本地绿色可预测 CI 绿色）。
任何新失败或回归 → 加入工作清单并回到 Phase 2。对于已批准计划或大范围改动场景，在最终声明前调用 completion-judge。
Phase 4 — 报告（LOW 自由度——不可跳过）
报告包含：范围、结果（GREEN | GREEN WITH QUARANTINE | BLOCKED）、各门禁命令与结果、已修复数量与区域、隔离/例外（逐条说明理由与跟踪建议）、环境阻塞（仅真实人工/基础设施门禁）。
除非被要求移除，保留 .cursor/green-repo-state.md 作为审计轨迹。如果有助于审查，建议将机械性修复与行为性修复分开提交。
适用场景
- 用户明确要求让整个仓库通过 CI 或达到绿色基线。
- 需要一次性清理跨多个区域的既有失败（类型、lint、测试、构建）。
- 需要可审计的修复轨迹与从零验证的绿色证明。
限制
- 必须获得明确授权才能触碰既有债务；否则先确认范围。
- 仅适用于全仓库范围；单一计划或单一模式应改用 complete-everything 或 burndown-full。
- 禁止任何伪造通过的手段（跳过、忽略、弱化断言、掩盖回归的快照更新）。
- 真实环境阻塞是唯一停止条件；偶发失败只能隔离并说明原因，不能假修。
- 关于具体收费、价格、平台支持等信息，资料中暂未提供。