By name: grill-with-docs description: 对代码变更进行深度审查，借助项目文档（ADR、CONTEXT）提供架构上下文。当用户说"审查这个"、"grill 这个 PR"、要求代码审查，或希望对变更进行深度而非表面的审查时使用。
Grill With Docs
对代码变更进行深度审查，利用项目文档提供架构上下文。
何时使用
当用户要求代码审查，或当你需要对变更进行比表面审查更深入的分析时。
流程
1. 收集上下文
在审查任何代码之前，收集相关的项目文档：
- ADR（架构决策记录）— 查找
.adr/或docs/adr/目录。这些记录了关键决策及其理由。审查应验证变更是否与现有决策一致，或是否需要新的 ADR。 - CONTEXT.md — 查找项目根目录或相关包中的
CONTEXT.md文件。这些描述了模块的领域概念和关系。审查应使用此词汇来评估变更是否正确地建模了领域。
参见 ADR-FORMAT.md 和 CONTEXT-FORMAT.md 了解这些文档的预期格式。
2. 审查变更
对于每个变更，评估：
- 领域忠实度 — 变更是否正确建模了领域？是否与 CONTEXT.md 中的概念一致？
- 架构一致性 — 变更是否与现有 ADR 一致？是否引入了需要新 ADR 的决策？
- 模块深度 — 变更是否改善了模块深度（简单接口，深层实现）？还是增加了浅层性？
- 接缝放置 — 变更是否在正确的位置引入了接缝？接缝是否被至少两个适配器（adapter）证明是合理的？
- 泄漏 — 变更是否将知识泄漏到了不该去的模块？是否违反了封装？
3. 产出审查结果
对每个发现：
- 引用支持该发现的 ADR 或 CONTEXT.md
- 如果变更与 ADR 矛盾，建议要么修改变更，要么创建新的 ADR
- 如果变更引入了领域概念但 CONTEXT.md 中没有，建议更新 CONTEXT.md
- 使用 LANGUAGE.md 中的词汇来描述架构问题
原则
- 文档是规范，代码是实现。 当代码与文档矛盾时，审查应标记这一点——并建议哪个应该改变。
- 审查应教学。 引用 ADR 和 CONTEXT.md 不仅是为了证明审查观点，也是为了教作者为什么做出这些决策。
- 没有文档不是借口。 如果项目没有 ADR 或 CONTEXT.md，审查仍应进行——但应建议创建它们，特别是对于架构性变更。