grill-with-docs

Stress-tests software design plans against repository domain glossary and documented decisions.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve?

It prevents “hand-wavy” design plans by forcing a shared understanding of your project’s domain language and decisions, then updating CONTEXT.md and ADRs as the reasoning solidifies.

Core Features & Use Cases

  • Relentless plan interview: Walk the design tree one question at a time, requiring clear answers before moving on.
  • Domain glossary enforcement: Detects term conflicts with CONTEXT.md and pushes for canonical terminology and precise definitions.
  • Documentation-in-the-loop updates: Updates CONTEXT.md inline as terms are resolved, and offers ADRs only when a decision has meaningful irreversibility, surprise, and trade-offs.
  • Code cross-checking: Uses repository exploration to resolve questions from the source of truth and surfaces contradictions between what’s claimed and what the code does.
  • Scenario stress-testing: Probes edge cases with concrete invented scenarios to clarify boundaries and relationships.

Quick Start

Use grill-with-docs to stress-test the current plan by saying: "Run grill-with-docs on my design plan for this repo, asking questions one at a time and updating CONTEXT.md and ADRs only when justified."

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 my software design plan against existing domain terminology?▼

To stress-test a software design plan against existing domain terminology, walk through the design tree one question at a time, cross-checking answers against your repository's documented glossary and source code to clarify trade-offs before implementation.

What is the best way to align my architecture review with an existing CONTEXT.md glossary?▼

Aligning an architecture review with a CONTEXT.md glossary requires step-by-step questioning that detects term conflicts, enforces canonical terminology definitions, and updates documentation inline as domain concepts are clarified.

When do I need to write an Architecture Decision Record during codebase exploration?▼

Write an Architecture Decision Record during codebase exploration only when a resolved design decision demonstrates meaningful irreversibility, surprise, and trade-offs, ensuring the documented outcome captures significant architectural constraints.

Can I use domain modeling to prevent hand-wavy integration planning across multiple branches?▼

Domain modeling prevents hand-wavy integration planning across multiple branches by probing edge cases with concrete scenarios, forcing precise relationship boundaries, and resolving terminology conflicts against the repository's source of truth.

How do I update domain documentation inline while clarifying software design boundaries?▼

Update domain documentation inline while clarifying software design boundaries by resolving terminology conflicts during the interview process, immediately writing canonical definitions into CONTEXT.md, and cross-checking claims against the codebase.