用途
maintenance-routine 是一个按计划运行的机械式维护技能，对代码仓库执行一次维护扫描，要么开出一个小的、可审查的 PR，要么报告没有发现任何符合条件的问题。它面向那些没人有时间做的维护工作：死代码、无法失败的测试、分层漂移、逐渐分叉的重复实现。
该技能提供方法，仓库提供参数。扫描范围、禁止路径、验证命令以及会击败静态搜索的框架陷阱都是仓库特有的，写在目标仓库的 .claude/routines.md 中。这种拆分是刻意的：例程自身的调优循环是“PR 被拒绝 → 调整例程”，而可调整的那一半必须位于例程能够对其开 PR 的仓库内部。
范围：每次调用只运行一种原型。运行多个是调度器的职责——错开它们，避免争用同一个运行器。
主要能力
技能内置七种原型，每种都有自己的资格测试，但共享同一份契约：
- dead-code-removal：删除静态搜索可证明不可达的代码，客观性最高。
- useless-test-pruner：找出无法失败的测试；优先修复，仅在最后手段才删除，客观性高。
- abstraction-police：修复仓库已写明的分层规则违规，客观性高。
- dup-unifier：收敛可证明会一起变化的重复实现，客观性中等。
- logic-bugfixer：将某个模块与其规格对照建模，以测试先行方式修复真实缺陷，客观性中等。
- logic-simplifier：梳理单个函数内部的逻辑，客观性低。
- abstraction-improver：压平不携带意义的间接层，客观性最低。
客观性预测首轮合并率。在新仓库采用例程时，先启用表格顶部的原型，等前面的原型稳定落地后再添加下面的行。
使用方式
调用命令：
/cadence:maintenance-routine <archetype>
<archetype> 为上述七种之一。从调度器触发时，整个提示可以就是这一行。
运行前必须通过四道预检门：
- 加载仓库配置。读取目标仓库的 .claude/routines.md。如果不存在，停止运行，不要从代码库推断范围、禁止路径或验证命令。打印 Repo Config Schema 中的模板，说明需要先填写并提交，然后结束运行。
- 加载原型。读取与本文件同级的 routines/<archetype>.md。它定义资格测试、工作流、PR 正文段落以及每次运行的 PR 上限。其规则是对本文件的补充，绝不放松本文件；两者冲突时以更严格者为准。
- 检测代码托管平台。GitHub 用 gh，GitLab 用 glab。检查哪个已安装并认证：
gh auth status 2>/dev/null || glab auth status 2>/dev/null
两者都没有则停止并报告。本技能示例使用 gh；glab 等价命令见 Forge Commands。下文“PR”在 GitLab 上指 MR。
- 建立绿色基线。在改动任何内容之前，于 HEAD 运行配置中的验证命令。如果基线是红的，停止并报告哪条命令失败。不要尝试修复它——一个来删除死代码却顺手修好无关失败测试的例程是越界的，更糟的是，红色基线会让之后所有“我的改动是安全的”声明无法被证伪。损坏的 HEAD 是人的问题。记录基线输出，之后用于对比。
工作流：预检（四道门）→ 选择本次运行目标（优先近期未触碰的区域，用 git log --since='60 days ago' --name-only 查看冷区，并在 PR 正文中说明选择及理由）→ 枚举候选 → 对每个候选应用原型的资格测试 → 对通过者做改动，最多到 PR 上限 → 运行完整验证套件并与基线对比 → 开 PR，或报告没有合格项。
例程契约
每种原型都遵守以下全部内容：
- 只开 PR，从不合并。不用 --auto，不因 CI 绿色而合并，不因改动琐碎而合并。合并是人的决定。这是让整个机制可无人值守运行的单条不变量。
- 无发现则不开 PR。空 PR 或凑数 PR 比沉默更糟：它消耗审查注意力，并污染用来判断例程是否值得运行的合并率信号。以“扫描了 X，考虑了 Y 和 Z，两者都未通过条件 3，未开任何 PR”结束是一次成功的运行。
- 遵守每次运行的 PR 上限。每种原型文件声明自己的上限（1–3）。上限关乎审查吞吐量，而非你发现了多少。多余候选放入 ## Observations。
- 分支命名用于核算：claude/<archetype>/<YYYY-MM-DD>-<n>，<n> 在一次运行内从 1 开始。不要自创其他方案。
- 避开禁止路径。配置中的列表，加上每个仓库都适用的：规格与决策记录（架构文档、ADR、领域词汇表、功能规格、归档变更记录）以及 CI 工作流定义。平台层面没有强制机制，分支保护和人工审查才是真正的防线。
- 不顺手修复注意到的问题。越出原型的改动会产生无人能对照既定意图审查的 diff。真实缺陷、模式问题、“顺便”清理都放入 ## Observations。
- 每个 PR 正文都包含 ## Verification 和 ## Observations。## Verification 粘贴实际命令输出，而非声称通过。## Observations 永不省略，没有内容时写 none。
- PR 保持单一主题且小。原型文件设定行数上限，超过上限意味着拆分，而不是“就这一次”。
验证
逐字运行配置中的命令。改动后未变绿的候选应放弃，而不是调试到通过——写入 ## Observations 并继续。在 ## Verification 中粘贴真实输出。当原型要求红转绿演示（logic-bugfixer 的失败测试、abstraction-police 的新 lint 规则）时，两半都必需。保持工作树干净：临时改动源码以测试某些内容的原型（useless-test-pruner、logic-simplifier）必须恢复它，并在继续前用 git status 确认。泄漏到 PR 中的临时改动会损害之后每一个例程 PR 的可信度。
合并率核算
分支命名约定就是全部埋点。几周后：
GitHub
gh pr list --search "head:claude/<archetype>" --state all
--json number,state,mergedAt,title
GitLab
glab mr list --source-branch "claude/<archetype>" --all
某个例程的落地率明显低于其他例程，说明其资格测试太松，或仓库配置缺少某个陷阱。收紧该原型的条件或补充 .claude/routines.md，然后让下一个周期拾取变更。
当没有合格项时
在运行输出中报告，而非开 PR：扫描了哪个目标及为何选择它、考虑了哪些候选、每个候选未通过哪个条件。这是低客观性原型最常见的结果，不是失败。把它凑成 PR 才是失败。
适用场景
适用于需要对代码仓库进行定期、机械式、可审查的小步维护，且希望无人值守运行、由人工审查合并的场景。尤其适合死代码清理、测试修剪、分层规则修复等客观性较高的维护任务。
限制
- 每次调用只运行一种原型。
- 依赖目标仓库提供 .claude/routines.md 配置，缺失则停止。
- 依赖 gh 或 glab 已安装并认证。
- 基线为红时停止，不修复。
- 只开 PR，从不合并。
- 仓库特有参数（扫描范围、禁止路径、验证命令、动态引用陷阱）本技能不提供默认值。
- 调度器卫生（显式固定模型、不在运行间携带状态、错开调度）的具体内容属于目标仓库自身的运维文档，本资料未提供更多细节。