grill-with-docs

Align engineering plans with repository domain language and documented architecture.

5|Updated May 21, 2026
One-click install
npx skills add https://github.com/TrebuchetDynamics/pi-package-goal --skill grill-with-docs-trebuchetdynamics
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/TrebuchetDynamics/pi-package-goal/tree/main/skills/grill-with-docs
Command: npx skills add https://github.com/TrebuchetDynamics/pi-package-goal --skill grill-with-docs-trebuchetdynamics

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents teams from building the wrong thing by forcing a plan to match the project’s established domain language and durable architectural decisions.

Core Features & Use Cases

  • Evidence-first domain alignment: Inspects the repo’s instructions, git state, CONTEXT.md/CONTEXT-MAP.md, ADRs, and relevant tests/manifests to resolve facts before asking.
  • One decision at a time: Converts ambiguity into a single owner-decision question with a recommended answer, waits for feedback, then proceeds only when unblocked.
  • Documentation with guardrails: Updates CONTEXT.md immediately when terms crystallize, and proposes ADRs only when decisions are hard-to-reverse, surprising without context, and true trade-offs.

Quick Start

Run grill-with-docs on your plan by asking it to restate the plan, identify the next hard uncertainty, scan the repo docs and code evidence, and then ask one owner-decision question at a time with a recommended answer.

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 engineering plan against existing repository architecture decisions?▼

You align an engineering plan with repository architecture by scanning domain language in CONTEXT.md and ADRs, then interrogating the plan branch-by-branch. This resolves owner decisions and terminology mismatches before code changes.

What is the best way to keep a refactoring plan aligned with a project's domain language?▼

The best way to align a refactoring plan with domain language is evidence-first repo scanning of CONTEXT.md and tests, followed by single-question owner-decision flow. Resolved terms immediately update CONTEXT.md to maintain durable alignment.

When do I need to create an Architecture Decision Record during plan review?▼

You create an Architecture Decision Record during plan review only when a resolved decision is hard-to-reverse, surprising without context, and a true trade-off. This sparing ADR creation criteria prevents unnecessary documentation clutter.

Can I use CONTEXT.md updates to resolve ambiguous domain terms during planning?▼

Yes, you can and should use CONTEXT.md updates to resolve ambiguous domain terms during planning. When terms crystallize after an owner-decision, CONTEXT.md is updated immediately to enforce evidence-first domain alignment.

Does plan review work without scanning repository code and manifests?▼

No, plan review requires evidence-first repo scanning of instructions, git state, CONTEXT.md, ADRs, and manifests. Scanning code and tests is required to resolve facts and align plans with documented architecture before asking owner-decisions.