# Grill With Docs

> 对代码变更进行深度审查，借助项目文档（ADR、CONTEXT）提供架构上下文。当用户说"审查这个"、"grill 这个 PR"、要求代码审查，或希望对变更进行深度而非表面的审查时使用。

- Skill: `alex-rachel/grill-with-docs` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add alex-rachel/grill-with-docs`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alex-rachel/grill-with-docs/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: alex-rachel (https://skillmd.com/u/alex-rachel)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alex-rachel/grill-with-docs

---


# Grill With Docs

对代码变更进行深度审查，利用项目文档提供架构上下文。

## 何时使用

当用户要求代码审查，或当你需要对变更进行比表面审查更深入的分析时。

## 流程

### 1. 收集上下文

在审查任何代码之前，收集相关的项目文档：

- **ADR**（架构决策记录）— 查找 `.adr/` 或 `docs/adr/` 目录。这些记录了关键决策及其理由。审查应验证变更是否与现有决策一致，或是否需要新的 ADR。
- **CONTEXT.md** — 查找项目根目录或相关包中的 `CONTEXT.md` 文件。这些描述了模块的领域概念和关系。审查应使用此词汇来评估变更是否正确地建模了领域。

参见 [ADR-FORMAT.md](ADR-FORMAT.md) 和 [CONTEXT-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](../improve-codebase-architecture/LANGUAGE.md) 中的词汇来描述架构问题

## 原则

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