grill-with-docs

Stress-test project plans against repository domain documentation and ADRs.

Updated Jul 2, 2025
One-click install
npx skills add https://github.com/janpeterd/dotfiles --skill grill-with-docs-janpeterd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/janpeterd/dotfiles/tree/main/dot_agents/skills/grill-with-docs
Command: npx skills add https://github.com/janpeterd/dotfiles --skill grill-with-docs-janpeterd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Helps you validate a project plan by challenging terminology, decisions, and domain relationships against the repository’s existing CONTEXT.md and ADRs, reducing ambiguity and future rework.

Core Features & Use Cases

  • Relentless plan interviews: Walks branch-by-branch through the design tree, resolving dependencies between decisions one by one.
  • Glossary and terminology enforcement: Detects conflicting term usage and proposes precise canonical terminology when language is fuzzy or overloaded.
  • Docs-first decision updates: Updates CONTEXT.md inline when concepts are resolved and offers ADRs sparingly when decisions meet clear “trade-off” criteria, while cross-checking claims against the codebase.

Quick Start

Ask the AI: “Use grill-with-docs to stress-test my plan against this repo’s CONTEXT.md and ADRs, and question each assumption until we reach shared, documented 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 a project plan against existing domain documentation?

You validate a project plan by stress-testing its assumptions against repository CONTEXT.md and ADRs. This process interviews decisions branch-by-branch, resolving dependencies and aligning terminology to reduce ambiguity and future rework.

When should I create an Architecture Decision Record during design?

You should create an Architecture Decision Record only when a decision is hard to reverse, surprising without context, and represents real trade-offs. This ensures documentation remains sparse and captures only critical architectural choices.

How does scenario-driven domain relationship validation work during architecture design?

Scenario-driven validation works by iteratively exploring the codebase and interviewing assumptions to resolve decision dependencies. It validates integration patterns and domain relationships against existing CONTEXT.md files to ensure architectural alignment.

Can I use this to review codebase architecture and update context documentation simultaneously?

Yes, you can review codebase architecture and update documentation simultaneously. The approach cross-checks design claims against the codebase, updates CONTEXT.md inline when concepts are resolved, and optionally creates ADRs for significant trade-offs.