Verified:GitHub

grill-with-docs

Validate a plan against an existing domain model and glossary.

1|Updated May 5, 2026

Search Tags:#architecture review #domain-driven-design #codebase validation #glossary alignment #ADR writing #context modeling #plan interrogation

Ready to run

npx skills add https://github.com/yashs33244/my-mac-claude --skill grill-with-docs-yashs33244

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/yashs33244/my-mac-claude/tree/main/skills/mattpocock/engineering/grill-with-docs
Command: npx skills add https://github.com/yashs33244/my-mac-claude --skill grill-with-docs-yashs33244

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill prevents misunderstandings and hidden design debt by rigorously validating a plan against your existing domain glossary, code, and documented decisions.

Core Features & Use Cases

Plan stress-testing: Walks the user through every branch of a design tree and forces decision-by-decision alignment.
Domain glossary correction: Detects conflicting terminology and proposes precise canonical terms when language is fuzzy or overloaded.
Inline documentation refinement: Updates CONTEXT.md immediately as terms are resolved and offers ADR creation only when a real, irreversible trade-off occurred.

Quick Start

Ask for grill-with-docs when you want to validate a proposed architecture by interviewing the design plan until all domain terms, dependencies, and trade-offs are clarified.

Frequently Asked Questions about grill-with-docs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I validate an architecture plan against my domain model?▼

To validate an architecture plan against your domain model, interrogate the proposed design's terminology, dependencies, and trade-offs one question at a time. This ensures shared understanding and aligns the plan with your existing domain truth.

When do I need to write an ADR during codebase validation?▼

You need to write an ADR during codebase validation only when a real, hard-to-reverse, and surprising trade-off is identified. ADRs should be created sparingly to document significant architectural decisions rather than routine resolutions.

How do I fix conflicting terminology during domain-driven design planning?▼

To fix conflicting terminology during domain-driven design planning, detect fuzzy or overloaded terms and propose precise canonical alternatives. Once resolved, immediately update your CONTEXT.md to maintain glossary alignment across the codebase.

Can I stress-test integration dependencies without exploring the codebase?▼

You can stress-test integration dependencies theoretically, but exploring the codebase when possible is recommended. Codebase exploration grounds the interrogation in actual implementation constraints, ensuring plan validation reflects technical reality.

What is the best way to maintain glossary alignment when planning new features?▼

The best way to maintain glossary alignment when planning new features is to relentlessly interrogate domain terms and update CONTEXT.md immediately as they resolve. This prevents misunderstandings and hidden design debt during architecture planning.

Does architecture review require one-question-at-a-time progression?▼

Architecture review using this approach requires one-question-at-a-time progression to walk through every branch of a design tree. This forces decision-by-decision alignment and ensures all terminology and dependencies are fully clarified.