grill-with-docs

Interrogates plans and designs while generating ADRs and domain glossaries.

1|Updated Aug 24, 2026
One-click install
npx skills add https://github.com/yamcodes/the-hat --skill grill-with-docs-yamcodes
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/yamcodes/the-hat/tree/main/skills/grill-with-docs
Command: npx skills add https://github.com/yamcodes/the-hat --skill grill-with-docs-yamcodes

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Design decisions made in conversation are often under-examined and then lost, leaving future engineers wondering why the code looks the way it does. This Skill runs a relentless interview to stress-test a plan or design and captures the outcomes as durable documentation. ## Core Features & Use Cases - Socratic Design Review: Delegates to a grilling interview that challenges assumptions and exposes weak spots in a plan before implementation. - Automatic ADR Creation: Records hard-to-reverse, surprising, trade-off-driven decisions as numbered ADRs in docs/adr/ using the Michael Nygard format. - Ubiquitous Language Glossary: Builds CONTEXT.md files with opinionated term definitions, aliases to avoid, relationships, and flagged ambiguities, plus CONTEXT-MAP.md for multi-context repos. - Use Case: While designing a billing module, the interview surfaces that "account" means both Customer and User; the Skill resolves the ambiguity into CONTEXT.md and writes an ADR explaining why Billing communicates via domain events instead of synchronous HTTP. ## Quick Start Ask the assistant to grill the current design plan and document the decisions and domain terms that emerge from the discussion.

Frequently Asked Questions about grill-with-docs

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

FAQPage Schema
How do I stress-test a design plan before implementation?▼

Run a structured grilling interview that relentlessly questions the plan's assumptions, trade-offs, and weak points. As the interview resolves decisions, ADRs and glossary entries are written to the repository so the reasoning is preserved.

When should I write an Architecture Decision Record?▼

Write an ADR only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. Easy-to-reverse or obvious choices do not need records and only add noise to docs/adr/.

What belongs in a domain glossary CONTEXT.md file?▼

Include only terms specific to the project's domain, with one-sentence definitions, aliases to avoid, relationships with cardinality, and an example dialogue. General programming concepts like timeouts or error types do not belong.

How do I handle multiple bounded contexts in one repository?▼

Create a CONTEXT-MAP.md at the repo root listing each context, its location, and how contexts relate through events or shared types. Each context then keeps its own CONTEXT.md with its local ubiquitous language.

What are the limitations of interview-based design review?▼

The interview only captures what is discussed, so undocumented constraints or unexamined alternatives can still slip through. It also requires an engaged participant willing to answer probing questions rather than a one-shot prompt.