rules-check-drift

/rules-check-drift — 让规则文件保持准确，而不是不断变长

你的规则文件——CLAUDE.md 或 AGENTS.md——是指导文件，而非文档：其中记录了基本规则、约定，以及一份最新的项目内容位置索引。唯一值得关注的失败模式就是内容有误：过时的规则或不准确的位置索引，会在之后每次运行时误导 Agent。此技能会根据刚刚发生的变更检查规则文件，并提出能让内容保持准确的最小修改。

错误的规则比缺少规则更糟。冗长的规则文件比精简的更糟。 大多数变更无需修改规则文件——添加错误或冗长的内容只会让情况更糟。

输入

• $ARGUMENTS — 可选的 diff 范围。默认为未提交和已暂存的变更（git diff HEAD）；如果失败，则使用 main...HEAD。
• 范围：项目的规则文件——CLAUDE.md 和／或 AGENTS.md，包括根目录文件和包级文件。（如果 CLAUDE.md 只是通过 @AGENTS.md 导入内容，请检查 AGENTS.md。）忽略 README、docs/ 和 .claude/ 下的 Agent／命令／技能文件。此技能只用于确保规则准确无误，其他内容不在范围内。

流程

1. 查看变更内容

运行 git diff <range> 和 git status。留意移动／重命名／删除的文件、新模块、约定变更，以及变更确立的任何新不变量。

2. 阅读当前规则文件

加载项目的规则文件——CLAUDE.md 或 AGENTS.md（以及任何包级文件）。逐条对照变更集检查其中的内容。

3. 仅标记以下三类问题

1. 已陈述的规则或事实现已不正确——例如，“路由位于 src/routes/”，但路由已迁移。→ 修正。
2. 架构索引已过时——路径或“项目内容位置”指引已与实际情况不符。→ 修正错误条目（不要逐一列出所有新文件）。
3. 必须长期遵守的新不变量——变更新增了一条今后必须持续遵守的规则（例如，“处理程序不得直接调用数据库——必须通过 repository/”）。→ 添加为一行。

其他内容一律不动。不要建议添加内容来记录新增功能（这是变更日志的工作——代码库才是事实来源），不要重述代码中已显而易见的内容，也不要添加无法指导未来工作的背景、理由或说明。

4. 按照 CLAUDE.md 的风格撰写每条建议

• 写成一个项目符号，不要写成一段话。 规则应是一行，而不是一篇文章。
• 保持索引准确——不要扩充。 修正错误路径，不要罗列新路径。
• 用自然语言陈述规则；引用代码库，绝不粘贴代码。 复制的代码会过时；代码库始终是准确的。好的示例：“遵循 src/core/errors/ 中的错误处理模式。”不好的示例：直接粘贴类代码。

输出

## Rules-file drift check — range: <range>

### Fix (now false)
| Where | What's wrong | Minimal fix |
|-------|--------------|-------------|
| "Architecture" map | routes moved `src/routes/` → `src/api/routes/` | update the one path |

### Add (new invariant only)
- <one-line rule> — established by <the change that made it durable>

### Checked, still true — no edit
- <areas you verified need no change>

如果没有内容过时：“这些变更并未影响规则文件的准确性——无需修改。”

规则

• 仅提供建议。 报告过时内容；只有调用者明确要求时，才应用／提交修改。
• 仅限规则文件（CLAUDE.md／AGENTS.md）。不包括 README 或文档。
• 默认保持精简。 如有疑问，不提出建议。
• 每次合并前运行（或作为 /piv-review-changes 的一部分运行），确保规则始终与代码保持一致。