grill-with-docs

Validate implementation plans against repository glossary and documented decisions.

Updated Mar 12, 2026
One-click install
npx skills add https://github.com/mpsuesser/workspace --skill grill-with-docs-mpsuesser
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/mpsuesser/workspace/tree/main/dotconfig/pi/agent/skills/.deprecated/grill-with-docs
Command: npx skills add https://github.com/mpsuesser/workspace --skill grill-with-docs-mpsuesser

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you validate and sharpen a plan by forcing alignment with your existing domain language, glossary, and documented architectural decisions.

Core Features & Use Cases

  • Relentless plan interrogation: Breaks the design tree into dependencies and resolves each decision one question at a time.
  • Terminology and glossary defense: Detects conflicting terms against CONTEXT.md and proposes precise canonical terminology.
  • Documentation-in-the-loop: Updates CONTEXT.md inline when terms are resolved and offers ADRs sparingly when a true trade-off was made.

Quick Start

Tell the skill the plan you want to implement and say where you think it touches your domain concepts and existing decisions.

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 implementation plan against existing domain modeling decisions?

Validating an implementation plan against domain modeling decisions requires breaking the design tree into dependencies and resolving each trade-off iteratively. The process cross-references your CONTEXT.md glossary and ADRs to ensure terminology alignment.

What is the best way to align new architecture requirements with a domain glossary?

Aligning architecture requirements with a domain glossary involves detecting conflicting terms against documented CONTEXT.md files. Canonical terminology is proposed inline, and the documentation updates occur directly when terms are resolved during the interrogation process.

When do I need to create an Architecture Decision Record for a domain modeling trade-off?

Creating an Architecture Decision Record is needed when a true domain modeling trade-off is resolved during plan interrogation. ADRs are created sparingly to document significant architecture decisions rather than minor terminology updates.

Can I update CONTEXT.md inline while clarifying architecture requirements?

Updating CONTEXT.md inline while clarifying architecture requirements is fully supported. As requirements clarification resolves conflicting terminology, the glossary updates are applied directly to maintain strict domain language alignment.

How does context mapping resolve trade-offs across multiple architecture branches?

Context mapping resolves trade-offs across multiple architecture branches by applying iterative, one-question-at-a-time interrogation. This workflow forces explicit resolution of dependencies and documents the outcome using ADR-format guidance when necessary.

Does this approach require an existing ADR workflow to function correctly?

An existing ADR workflow is not strictly required to function, but having documented architecture decisions enhances the validation process. The skill provides ADR-format guidance and creates records sparingly when true trade-offs are identified.