PluginBench
Skill
Pass
Audit score 90

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
Prerequisites
  • Existing codebase with domain code to explore
  • Optional: CONTEXT.md file defining your domain glossary
  • Optional: docs/adr/ directory with existing Architecture Decision Records
Claude Code
Cursor
Windsurf
Cline

How to use grill-with-docs

  1. 1.Install the skill using the provided npm command
  2. 2.Describe the plan or feature you want to stress-test
  3. 3.Answer questions one at a time as they are asked
  4. 4.Allow the skill to explore your codebase and documentation to find answers
  5. 5.Review and confirm terminology updates to CONTEXT.md as they are proposed
  6. 6.Approve ADR creation only when decisions are hard to reverse, surprising without context, and result from real trade-offs

Use cases

Good for
  • 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
Who it's for
  • 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

When should I use this skill instead of just discussing the plan?

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.

Will this create a lot of documentation I have to maintain?

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.

What if my project doesn't have CONTEXT.md or ADRs yet?

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.

Can it find answers in my code instead of asking me?

Yes. It explores your codebase and existing documentation first. It only asks you questions that can't be answered by examining the code.

What if my code contradicts what I'm saying?

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:

  1. Hard to reverse — 之后改主意的成本有意义
  2. Surprising without context — 未来读者会疑惑“为什么这样做?”
  3. The result of a real trade-off — 确实有真实替代方案,并且你基于具体原因选择了一个

如果三者缺一,就跳过 ADR。使用 ADR-FORMAT.md 中的格式。

</supporting-info>