grill-with-docs

Name: grill-with-docs
Availability: InStock
Author: Acend

Validate design plans against domain glossary and documented decisions.

Updated May 25, 2026

Search Tags:#decision making #domain modeling #architecture review #documentation alignment #codebase inspection #ADR writing #glossary refinement

Ready to run

npx skills add https://github.com/AcendWay/ai-skills-library --skill grill-with-docs-acendway

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/AcendWay/ai-skills-library/tree/main/skill-folders/grill-with-docs
Command: npx skills add https://github.com/AcendWay/ai-skills-library --skill grill-with-docs-acendway

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you validate a design or plan by forcing precise alignment between your terminology, your documented decisions, and the underlying domain model.

Core Features & Use Cases

Relentless plan interrogation: Interviews you step-by-step until you reach shared understanding of each branch of the design.
Domain glossary sharpening: Challenges conflicting or vague terms and updates the project’s CONTEXT.md glossary as terms get resolved.
Decision capture via ADRs: Offers to create ADRs sparingly, only when changes reflect hard-to-reverse trade-offs, are surprising without context, and represent real alternatives.

Quick Start

Use grill-with-docs to stress-test your plan by answering one question at a time until your terminology and documentation (CONTEXT.md and ADRs) accurately reflect the decisions you make.

Frequently Asked Questions about grill-with-docs

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

FAQPage Schema

How do I validate an architecture plan against existing domain documentation?▼

To validate an architecture plan against existing documentation, interrogate your design assumptions step-by-step against your domain glossary to ensure terminology consistency and capture trade-offs in ADRs.

When should I write an ADR for a design decision?▼

You should write an ADR when a design change reflects a hard-to-reverse trade-off, is surprising without context, and represents a real alternative among documented architectural decisions.

How do I keep a domain glossary consistent during integration planning?▼

Keep a domain glossary consistent during integration planning by challenging conflicting or vague terms during design interrogation and applying controlled updates to your CONTEXT.md file as terms are resolved.

What is the best way to stress-test a design before implementation?▼

The best way to stress-test a design before implementation is conducting incremental, one-question-at-a-time exploration that cross-references your codebase and existing documentation to align assumptions.

Does architecture review require an existing CONTEXT.md file?▼

Architecture review requires an existing or planned CONTEXT.md file because the process validates terminology alignment and applies controlled updates directly to the domain glossary documented there.

Why does terminology alignment fail during codebase inspection?▼

Terminology alignment fails during codebase inspection when a proposed design introduces conflicting or vague terms that diverge from the documented domain glossary and existing architectural decisions.