grill-with-docs

Designs final-state system architecture for all stages through domain confrontation and documentation.

7|Updated May 13, 2026
One-click install
npx skills add https://github.com/DawnMoon1542/agents-skills --skill grill-with-docs-dawnmoon1542
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/DawnMoon1542/agents-skills/tree/main/workflow/grill-with-docs
Command: npx skills add https://github.com/DawnMoon1542/agents-skills --skill grill-with-docs-dawnmoon1542

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After brainstorming confirms requirements, teams often jump into implementation without a coherent multi-stage design, leading to inconsistent terminology, missing architecture decisions, and transitional compatibility hacks. This Skill enforces a structured design phase that confronts every stage's responsibilities, interfaces, and data flows before any planning or coding begins. ## Core Features & Use Cases - Stage-by-stage design confrontation: Reads the brainstorming index and iterates through every stage, confirming terminology, responsibilities, interfaces, data flow, error handling, and test strategy one question at a time. - Living documentation: Incrementally writes per-stage design files under docs/grill/, updates CONTEXT.md glossaries, and creates ADRs only for hard-to-reverse decisions with real trade-offs. - Final-state-first discipline: Explicitly forbids transitional compatibility mechanisms (adapters, dual reads/writes, feature flags) unless the final requirement demands them, while still requiring data safety and release-operation assessment. - Use Case: After brainstorming a multi-stage migration of an ordering system, use this Skill to produce confirmed design documents for each stage, an updated domain glossary, and ADRs before handing everything to a writing-plans workflow. ## Quick Start Use the grill-with-docs skill to design all stages from the brainstorming index at docs/brainstorming/2024-01-15-user-auth.md before planning implementation.

Frequently Asked Questions about grill-with-docs

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

FAQPage Schema
How do I design a multi-stage feature before implementation?

Read the brainstorming index containing the full requirements and stage breakdown, then confront each stage's terminology, responsibilities, interfaces, data flow, and error handling one question at a time. Write each confirmed stage design to docs/grill/ and only proceed to planning after all stages are user-confirmed.

When should I create an Architecture Decision Record?

Create an ADR only when a decision is hard to reverse, would confuse future readers without context, and involved a real trade-off between alternatives. Easy-to-reverse or obvious choices do not need records; transitional development mechanisms should never get ADRs.

Does this design approach allow backward compatibility layers?

No transitional compatibility mechanisms are allowed by default: no adapters, dual reads/writes, deprecated aliases, or feature-flag rollouts. Intermediate stages may be undeployable. Only compatibility explicitly required by the final requirement is designed, while data safety and migration protection remain mandatory.

What documents does a stage design workflow produce?

Each stage produces a design file under docs/grill/ covering responsibilities, architecture position, interfaces, data flow, error handling, cross-stage contracts, test strategy, and explicit exclusions. The workflow also updates CONTEXT.md glossaries, CONTEXT-MAP.md, ADRs, and the brainstorming index status.

Why must all stages be designed before writing implementation plans?

The hard gate ensures cross-stage contracts, shared terminology, and the final architecture are consistent before any planning begins. Designing only the first stage risks downstream conflicts, duplicated responsibilities, and scope creep that surface too late to fix cheaply.