grill-with-docs

Challenges plans against documented domain models and CONTEXT.md glossaries.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents interface and implementation drift by forcing your plan to match the project’s existing glossary and recorded architectural decisions.

Core Features & Use Cases

  • Relentless domain-model interrogation: Challenges ambiguous or conflicting assumptions by asking targeted questions until terms and boundaries are unambiguous.
  • Glossary alignment with CONTEXT.md: Updates the repository glossary inline as terms get resolved, while keeping it free of implementation details.
  • Decision capture via ADRs (sparingly): Offers to create an ADR only when the decision is hard to reverse, surprising without context, and a result of a real trade-off.

Quick Start

Ask an AI to run the grill-with-docs session against your plan and your codebase to reconcile terminology and update CONTEXT.md and any necessary ADRs inline.

Frequently Asked Questions about grill-with-docs

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

FAQPage Schema
How do I prevent specification drift between my UI design and the codebase domain model?

Relentless domain-model interrogation challenges ambiguous assumptions by asking iterative single-question negotiations, cross-references your codebase to resolve terminology conflicts, and updates CONTEXT.md inline to maintain glossary alignment without implementation details.

How do I validate a feature plan against existing architecture decisions before implementation?

Architecture alignment validates your plan by challenging undocumented assumptions against the repository's recorded decisions, offering to create an ADR only when the decision is hard to reverse, surprising without context, and a result of a real trade-off.

When should I write an ADR versus just updating the glossary in CONTEXT.md?

Write an ADR only when a decision is hard to reverse, surprising without context, and the result of a real trade-off, whereas you update CONTEXT.md continuously to capture resolved terminology and keep the glossary free of implementation details.

Does domain modeling work for resolving terminology conflicts in architecture discussions?

Yes, domain modeling resolves terminology conflicts by applying iterative single-question negotiation to challenge conflicting assumptions until terms and boundaries are unambiguous, then updating the repository glossary inline.

What is the best way to maintain glossary alignment without leaking implementation details?

The best way to maintain glossary alignment is to update CONTEXT.md inline as terms get resolved during plan interrogation, deliberately keeping the documented glossary free of implementation details to prevent interface drift.