grill-with-docs

Stress-test product plans against domain glossary and documented decisions.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents misaligned plans and fuzzy terminology by forcing a shared understanding of the domain model and updating the project’s glossary and decision records as clarity emerges.

Core Features & Use Cases

  • Relentless plan interrogation: Questions every assumption in the proposed design until dependencies between decisions are resolved.
  • Terminology sharpening: Detects conflicts with existing CONTEXT.md language and proposes canonical terms when users use vague or overloaded wording.
  • Docs-first outcomes: Updates CONTEXT.md inline when terms are resolved and offers ADRs only when a decision is hard to reverse, surprising without context, and involves real trade-offs.

Quick Start

Use grill-with-docs to walk through your current plan step by step and refine it against the existing domain model and documentation.

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 product plan against an existing domain model and glossary?

To stress-test a product plan against a domain model, you interrogate design assumptions iteratively, checking terminology and concept boundaries against existing documentation to detect conflicts and harden the system design.

When should I create an Architecture Decision Record for a system design choice?

You should create an Architecture Decision Record when a design choice involves real trade-offs, is hard to reverse, or would be surprising without prior context, ensuring documented decisions are captured systematically.

How do I align project terminology and resolve conflicts in a domain glossary?

To align project terminology, you compare newly proposed wording against existing CONTEXT.md language, detect vague or overloaded terms, and update the glossary inline with canonical terms as clarity emerges.

What is the best way to reconcile a design-tree walkthrough with codebase reality?

The best way to reconcile a design-tree walkthrough with codebase reality is through iterative single-question prompting, exploring the codebase on demand to resolve decision dependencies and verify implementation alignment.

Do I need existing CONTEXT.md and ADR artifacts to review a system plan?

Existing CONTEXT.md and ADR artifacts are required to effectively review a system plan, as they provide the prior domain glossary and documented decisions needed to detect conflicts and align terminology.

How does detecting CONTEXT language conflicts improve documentation alignment?

Detecting CONTEXT language conflicts improves documentation alignment by immediately identifying when user wording contradicts existing domain definitions, triggering inline updates to CONTEXT.md to maintain a shared understanding.