grill-with-docs

Interviews a design against project docs and records decisions as ADRs and glossary terms.

2|Updated Jul 11, 2026
One-click install
npx skills add https://github.com/MoofonLi/dev-ready --skill grill-with-docs-moofonli
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/MoofonLi/dev-ready/tree/main/.agents/skills/grill-with-docs
Command: npx skills add https://github.com/MoofonLi/dev-ready --skill grill-with-docs-moofonli

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Designs and plans often contain hidden assumptions that only surface during implementation. This Skill runs a structured interview that challenges a plan against the project's existing documentation, capturing durable decisions as ADRs and glossary terms before specification begins. ## Core Features & Use Cases - Document-grounded interrogation: Grills the phase scope against on-disk artifacts such as requirements, phase plans, binding ADRs, architecture boundaries, and CLI exit codes rather than intuition. - Decision capture as you go: Anything settled during the interview that outlives the phase is written into a new ADR in docs/decisions/ or a term in CONTEXT.md. - Spec Loop integration: Acts as the first step of the internal Spec Loop (grill-with-docs → to-spec → to-tickets → implement), feeding settled outcomes into the next specification step. - Use Case: Before writing a spec for a new API phase, run the interview to pressure-test the phase plan against existing ADRs and module boundaries, recording any new architectural decisions along the way. ## Quick Start Ask your agent to run the grill-with-docs skill to interview the current phase plan against the project docs and record any lasting decisions as ADRs.

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 design against existing project documentation?

Run a grilling interview that challenges the design scope against on-disk artifacts: requirements, phase plans, binding ADRs, architecture boundaries, and CLI exit codes. Settled decisions that outlive the phase are recorded as new ADRs or glossary terms.

What is an ADR and when should I write one?

An ADR (Architecture Decision Record) documents a binding technical decision. Write one whenever an interview or design discussion settles something that outlives the current phase, storing it in docs/decisions/ so future work respects it.

How does grill-with-docs fit into a spec-driven workflow?

It is the first step of the Spec Loop: grill-with-docs → to-spec → to-tickets → implement. The interview settles open questions against existing docs, and everything else flows into the specification produced at the next step.

Can this skill be invoked automatically by the AI model?

No. The skill sets disable-model-invocation and its policy disallows implicit invocation, so it only runs when the user explicitly starts the grilling session.

What documents does the grilling interview read?

It reads the FRs in docs/requirements.md, the phase section of the versioned plan under docs/handoff/, binding ADRs in docs/decisions/, module boundaries in docs/architecture.md, and exit codes in docs/cli-spec.md.