grill-with-docs

Stress-test project plans against repository documentation and update CONTEXT.md and ADRs.

2|Updated Mar 3, 2026
One-click install
npx skills add https://github.com/MomoDaviluke/star-citizen-promotion --skill grill-with-docs-momodaviluke
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/MomoDaviluke/star-citizen-promotion/tree/main/.agents/skills/grill-with-docs
Command: npx skills add https://github.com/MomoDaviluke/star-citizen-promotion --skill grill-with-docs-momodaviluke

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise.

Core Features & Use Cases

  • Relentlessly question the plan to surface ambiguities, inconsistencies, and gaps in domain language.
  • Update CONTEXT.md inline and create ADRs when decisions are hard to reverse, ensuring decisions are traceable.
  • Explore the codebase and existing docs (CONTEXT.md, ADRs) to validate decisions against implementation and promote stakeholder alignment.

Quick Start

Begin by outlining your current plan and let me relentlessly challenge every assumption until decisions are codified in CONTEXT.md and 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 stress-test a project plan against existing documentation and domain language?

Decision tracking through Architecture Decision Records captures hard-to-reverse choices, ensuring they remain traceable over time. You create ADRs when decisions crystallize during plan validation to maintain a permanent record of why specific architectural paths were chosen.

When do I need to update CONTEXT.md during project planning?

You can use this grilling approach for any project scale where domain language consistency and decision traceability matter. It works by relentlessly questioning your plan against existing CONTEXT.md and ADRs to promote stakeholder alignment regardless of project size.

What is the best way to ensure architectural decisions are traceable in documentation?

The best way to ensure decisions are traceable is by updating CONTEXT.md inline and recording ADRs when decisions become hard to reverse. This captures changes directly as they crystallize, linking domain language updates to their underlying architectural rationale.

Why does my project plan have inconsistencies with the codebase domain language?

Project plans develop inconsistencies with domain language when assumptions are not challenged against existing CONTEXT.md and ADRs. Grilling your plan against concrete codebase scenarios surfaces these gaps and ambiguities before implementation begins.