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.