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.