grill-with-docs

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. 审查变更

对于每个变更，评估：

1. 领域忠实度 — 变更是否正确建模了领域？是否与 CONTEXT.md 中的概念一致？
2. 架构一致性 — 变更是否与现有 ADR 一致？是否引入了需要新 ADR 的决策？
3. 模块深度 — 变更是否改善了模块深度（简单接口，深层实现）？还是增加了浅层性？
4. 接缝放置 — 变更是否在正确的位置引入了接缝？接缝是否被至少两个适配器（adapter）证明是合理的？
5. 泄漏 — 变更是否将知识泄漏到了不该去的模块？是否违反了封装？

3. 产出审查结果

对每个发现：

• 引用支持该发现的 ADR 或 CONTEXT.md
• 如果变更与 ADR 矛盾，建议要么修改变更，要么创建新的 ADR
• 如果变更引入了领域概念但 CONTEXT.md 中没有，建议更新 CONTEXT.md
• 使用 LANGUAGE.md 中的词汇来描述架构问题

原则

• 文档是规范，代码是实现。 当代码与文档矛盾时，审查应标记这一点——并建议哪个应该改变。
• 审查应教学。 引用 ADR 和 CONTEXT.md 不仅是为了证明审查观点，也是为了教作者为什么做出这些决策。
• 没有文档不是借口。 如果项目没有 ADR 或 CONTEXT.md，审查仍应进行——但应建议创建它们，特别是对于架构性变更。