grill-with-docs
vinvcn/mattpocock-skills-zh-cn
Stress-test plans against your domain model and sharpen terminology while updating docs inline.
What is grill-with-docs?
A grilling session that challenges your plan against existing domain language and documented decisions. Use when you want to validate architectural or design decisions against your project's CONTEXT.md and ADRs, ensuring terminology is precise and decisions are well-reasoned.
- Asks targeted questions one at a time about each aspect of your plan, waiting for feedback before proceeding
- Explores codebase and existing documentation (CONTEXT.md, ADRs) to answer questions rather than asking you
- Challenges fuzzy or overloaded terminology against your glossary and proposes canonical terms
- Stress-tests domain relationships with concrete scenarios to expose edge cases and boundary conditions
- Updates CONTEXT.md and ADRs inline as decisions crystallize, without waiting until the end
- Cross-references your explanations against actual code to identify inconsistencies
How to install grill-with-docs
npx skills add https://github.com/vinvcn/mattpocock-skills-zh-cn --skill grill-with-docs- Existing codebase with domain code to explore
- Optional: CONTEXT.md file defining your domain glossary
- Optional: docs/adr/ directory with existing Architecture Decision Records
How to use grill-with-docs
- 1.Install the skill using the provided npm command
- 2.Describe the plan or feature you want to stress-test
- 3.Answer questions one at a time as they are asked
- 4.Allow the skill to explore your codebase and documentation to find answers
- 5.Review and confirm terminology updates to CONTEXT.md as they are proposed
- 6.Approve ADR creation only when decisions are hard to reverse, surprising without context, and result from real trade-offs
Use cases
- Validating a new feature design against your domain model before implementation
- Clarifying ambiguous terminology in a growing codebase by grounding it in concrete scenarios
- Documenting architectural decisions (ADRs) as they emerge from design discussions
- Stress-testing a refactoring plan against existing domain language and constraints
- Identifying hidden dependencies between design decisions by walking the decision tree
- Architects and senior engineers designing new systems or major features
- Teams maintaining multiple bounded contexts who need consistent domain language
- Projects with existing CONTEXT.md and ADR documentation that want to keep it current
- Developers preparing to implement complex domain logic and wanting to validate assumptions first
grill-with-docs FAQ
Use it when you want systematic validation against your domain model and documented decisions. It's especially valuable for complex domains, multi-context systems, or when terminology has become fuzzy across your team.
No. It only updates CONTEXT.md with glossary terms (no implementation details) and creates ADRs sparingly—only for decisions that are hard to reverse, surprising without context, and result from real trade-offs.
The skill will create them lazily—only when there's content to write. It creates CONTEXT.md when the first term is resolved and docs/adr/ when the first ADR is needed.
Yes. It explores your codebase and existing documentation first. It only asks you questions that can't be answered by examining the code.
The skill will point out the contradiction immediately, forcing you to clarify whether the code is wrong, your explanation was imprecise, or your understanding has evolved.
Full instructions (SKILL.md)
Source of truth, from vinvcn/mattpocock-skills-zh-cn.
name: grill-with-docs description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
<what-to-do>围绕这个计划的每个方面持续追问我,直到我们达成共同理解。沿着 design tree 的每个分支往下走,逐一解决决策之间的依赖。对每个问题,都提供你推荐的答案。
一次只问一个问题,并等待我对每个问题的反馈后再继续。
如果某个问题可以通过探索 codebase 来回答,就去探索 codebase,而不是问我。
</what-to-do> <supporting-info>Domain awareness
探索 codebase 时,也查找现有文档:
File structure
大多数 repos 只有一个 context:
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
如果根目录存在 CONTEXT-MAP.md,说明 repo 有多个 contexts。这个 map 指向每个 context 的位置:
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← system-wide decisions
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← context-specific decisions
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
懒创建文件:只有在有内容可写时才创建。如果没有 CONTEXT.md,在第一个 term 被解决时创建。如果没有 docs/adr/,在第一个 ADR 需要时创建。
During the session
Challenge against the glossary
当用户使用的 term 与 CONTEXT.md 中的现有语言冲突时,立即指出。“Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?”
Sharpen fuzzy language
当用户使用含糊或 overloaded terms 时,提出一个精确的 canonical term。“You're saying 'account' — do you mean the Customer or the User? Those are different things.”
Discuss concrete scenarios
讨论 domain relationships 时,用具体场景做 stress-test。发明能探测 edge cases 的场景,迫使用户精确说明概念之间的边界。
Cross-reference with code
当用户说明某件事如何工作时,检查代码是否一致。如果发现矛盾,指出来:“Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?”
Update CONTEXT.md inline
当一个 term 被解决时,立即更新 CONTEXT.md。不要攒到最后;随着发生就捕获。使用 CONTEXT-FORMAT.md 中的格式。
CONTEXT.md 应完全不包含实现细节。不要把 CONTEXT.md 当作 spec、scratch pad 或实现决策仓库。它只是 glossary,除此之外不承担别的职责。
Offer ADRs sparingly
只有以下三点全部为真时,才提议创建 ADR:
- Hard to reverse — 之后改主意的成本有意义
- Surprising without context — 未来读者会疑惑“为什么这样做?”
- The result of a real trade-off — 确实有真实替代方案,并且你基于具体原因选择了一个
如果三者缺一,就跳过 ADR。使用 ADR-FORMAT.md 中的格式。
</supporting-info>Related skills
More from vinvcn/mattpocock-skills-zh-cn and the wider catalog.

improve-codebase-architecture
Find architecture friction and propose deepening opportunities to improve testability and AI-navigability.

migrate-to-shoehorn
Replace unsafe `as` type assertions in tests with type-safe shoehorn alternatives.

obsidian-vault
在 Obsidian vault 中使用 wikilinks 和 index notes 搜索、创建并管理 notes。Use when user wants to find, create, or organize notes in Obsidian.

prototype
Build throwaway prototypes to validate designs and state models before committing to production code.

qa
交互式 QA session,用户以对话方式报告 bugs 或 issues,agent 创建 GitHub issues。后台探索 codebase 以获取 context 和 domain language。Use when user wants to report bugs, do QA, file issues conversationally, or mentions "QA session".

request-refactor-plan
通过 user interview 创建带 tiny commits 的详细 refactor plan,然后 file as a GitHub issue。Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.