grill-with-docs

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

Updated May 10, 2026
One-click install
npx skills add https://github.com/rexshihaoren/rexy_vibing_setup --skill grill-with-docs-rexshihaoren
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/rexshihaoren/rexy_vibing_setup/tree/main/docs/ai/skills/grill-with-docs
Command: npx skills add https://github.com/rexshihaoren/rexy_vibing_setup --skill grill-with-docs-rexshihaoren

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Plans often contain fuzzy terminology, hidden contradictions with existing code, and undocumented decisions that future contributors cannot understand. This Skill runs an interrogation-style session that challenges your plan against the project's domain model and records resolved terms and decisions as documentation. ## Core Features & Use Cases - Socratic Plan Grilling: Asks one question at a time, walking each branch of the design tree and providing a recommended answer for every question. - Terminology Sharpening: Detects vague or conflicting terms, proposes canonical language, and updates CONTEXT.md inline as terms are resolved. - Decision Recording: Offers to write ADRs in docs/adr/ 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 to reconcile your plan with the existing glossary, discover that the code only supports full cancellation, and record the resolution in CONTEXT.md plus an ADR. ## Quick Start Ask the agent to grill you on your implementation plan for a new feature and update the project documentation as decisions are made.

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 tree. Each question comes with a recommended answer, and questions answerable from the codebase are resolved by exploring the code directly.

How to keep a project glossary consistent with domain language?▼

Maintain a CONTEXT.md file that defines canonical terms, lists aliases to avoid, and flags ambiguities. Update it inline whenever a term is resolved during design discussions rather than batching changes later.

When should I write an Architecture Decision Record?▼

Write an ADR only when all three conditions hold: the decision is hard to reverse, it is surprising without context, and it resulted from a genuine trade-off between alternatives. Skip ADRs for easily reversed or obvious choices.

Does this approach work with multiple bounded contexts in one repo?▼

Yes. A CONTEXT-MAP.md at the repo root lists each context, its location, and its relationships. The session infers which context the current topic belongs to and asks when unclear, keeping context-specific ADRs near their code.

What are the limitations of documentation-driven plan review?▼

It depends on the user answering questions honestly and on the codebase being explorable. It does not execute or prototype the plan, so runtime behavior and performance characteristics remain unverified until implementation.