grill-with-docs

Stress-tests plans through structured questioning while updating CONTEXT.md glossaries and ADR documentation.

Updated May 23, 2026
One-click install
npx skills add https://github.com/Oatse/CWE-Automation --skill grill-with-docs-oatse
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/Oatse/CWE-Automation/tree/main/.agents/skills/grill-with-docs
Command: npx skills add https://github.com/Oatse/CWE-Automation --skill grill-with-docs-oatse

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Plans often contain fuzzy terminology, hidden contradictions with existing code, and undocumented decisions that future engineers will question. This Skill runs an interrogation-style session that challenges your plan against your project's domain language and documented decisions, capturing resolutions in CONTEXT.md and ADRs as they happen. ## Core Features & Use Cases - Relentless plan interrogation: Asks one question at a time, walking each branch of the design tree and providing a recommended answer for every question. - Terminology sharpening: Challenges terms that conflict with the existing CONTEXT.md glossary, proposes canonical terms for vague language, and updates the glossary inline as terms are resolved. - Selective ADR creation: Offers Architecture Decision Records only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Use Case: Before implementing a partial order cancellation feature, run a grilling session that discovers your code cancels entire Orders, resolves the contradiction, adds 'Cancellation' to CONTEXT.md, and records an ADR explaining the chosen approach. ## Quick Start Grill my plan for the new billing retry feature and update our domain docs as we go.

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 software design plan before implementing it?

Run a grilling session that interviews you one question at a time about every branch of the design, providing a recommended answer for each question. Questions answerable from the codebase are resolved by exploring the code directly instead of asking.

How to keep a domain glossary consistent with code during design discussions?

Maintain a CONTEXT.md glossary at the repo root and update it inline whenever a term is resolved during discussion. When usage conflicts with the glossary, the contradiction is called out immediately so you can pick a canonical term.

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 genuine trade-off between alternatives. If any of the three conditions is missing, skip the ADR to avoid documentation noise.

Does this work with multiple bounded contexts in one repo?

Yes. A CONTEXT-MAP.md at the repo root lists each context and its relationships, with per-context CONTEXT.md and docs/adr directories. The session infers which context the current topic belongs to and asks when unclear.

What are the limitations of a documentation-driven grilling session?

It depends on the user answering questions iteratively, so it is slower than autonomous plan review. It also only documents decisions when they meet the strict ADR criteria, so minor choices remain undocumented by design.