样例：评审规范
下面是 CampusClaw 项目《评审与完成定义规范 · CampusClaw》的原文，逐条列出，可直接照抄。
适用：全部变更；常驻在
被谁读到：
AGENTS.md 的「门禁 / 提交与评审」段，每次会话都会读到被谁读到：
AGENTS.md + 技能「按规范评审一次变更」1. 完成定义（Definition of Done）
一条变更在同时满足下列五条后才算完成：
- 规约里列出的场景全部满足，越权场景也有对应用例；
make check全绿（go-vet / go-build / go-test / fe-typecheck / fmt-check / complexity / layout / secret-scan / prompt-guard / instruction-diff / hook-test / gate-tamper）；- 涉及提示词改动时，评测集已跑过并归档结果；
- 文档同步：
README.md、数据字典、页面清单随改动更新； - 验证记录归档到
docs/。
判据：逐条打勾，勾不上的那一条就是未完成的部分。
2. 变更规模上限
单次变更不超过 tasks.md 里的一组任务。超出即拆分为多次变更——规模越大，评审越趋近于走过场。
3. 评审检查表
| 谁来审 | 看什么 |
|---|---|
| 人 | 规约覆盖（场景是否真正满足）、授权判定（跨班是否按 404 处理）、数据迁移（是否可回滚）、提示词改动（是否跑过评测） |
| Harness | 规范一致性：分层与依赖方向、命名、错误码登记、重复代码 |
| 格式化工具 | 代码风格，不占用评审时间 |
4. 责任人与时限
每次变更指定一名评审人；评审请求在一个工作日内响应；超期由提出者升级到组内例会，而不是自行合并。
5. 门禁必跑
合并前必须执行 make check。不得为了让门禁变绿而放宽其中的检查或删断言，也不得跳过本地提交钩子。
6. 例外书面化
确有理由保留旧写法时，把例外写进对应的规范文件并注明理由与失效条件；留在会话里的口头豁免无效。
7. 证据归档
变更说明、验证记录、评审结论归档到 docs/，按变更名可一次检索到三份材料。提交信息尾部写三个字段，值必须查得到（指向的文件存在、命令跑得出）：
Change: 2026-10-27-add-homework-submission
Verify: make check / apitest
Evidence: docs/changes/2026-10-27-add-homework-submission.md8. 改这些文件要人审
AGENTS.md、CLAUDE.md、.cursor/、.githooks/、openspec/、Makefile、scripts/、.github/。
改它们的变更要在说明里写清改了什么、为什么、怎么验证；助手不得自行放宽其中的检查。
违反时
先判定是「流程没走」还是「判定不清」：前者退回补流程，后者改本文件并记入变更说明。