grill-with-docs

Challenge proposed plans against codebase language and documented decisions.

Updated Jul 17, 2026
One-click install
npx skills add https://github.com/kartikkabadi/skills --skill grill-with-docs-kartikkabadi
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/kartikkabadi/skills/tree/main/grill-with-docs
Command: npx skills add https://github.com/kartikkabadi/skills --skill grill-with-docs-kartikkabadi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps teams pressure-test a plan against the language, assumptions, and documented decisions already present in a codebase. It reduces ambiguity by forcing terms to be precise and surfacing contradictions between proposed changes and existing documentation.

Core Features & Use Cases

  • Relentless clarification: Asks one question at a time and recommends an answer for each branch of the plan.
  • Codebase-aware interrogation: Checks the repository directly when a question can be answered from existing code or documentation.
  • Glossary and docs alignment: Updates CONTEXT.md as terms are resolved and suggests ADRs when decisions are hard to reverse, surprising, and trade off alternatives.
  • Use case: A team wants to introduce a new workflow and needs to confirm the terminology, boundaries, and documentation implications before implementation.

Quick Start

Ask me to grill your plan against the current codebase and documentation, then answer each question one by one as I challenge assumptions and refine the terminology.

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 an architecture plan against existing domain language in a codebase?

To stress-test an architecture plan, interrogate the proposed changes against existing codebase terminology and documented decisions. Resolve ambiguity by forcing precise definitions, updating glossaries, and creating ADRs for decisions involving hard-to-reverse trade-offs.

When do I need to create an Architecture Decision Record during a design review?

Create an Architecture Decision Record during a design review when a proposed decision is hard to reverse, reflects real trade-offs between alternatives, and contradicts or significantly extends existing domain documentation and terminology within the codebase.

What is the best way to align team terminology before implementing a new workflow?

The best way to align terminology is through relentless clarification, asking questions one by one against the codebase, updating a shared glossary like CONTEXT.md as terms are resolved, and surfacing contradictions before implementation begins.

Can I check existing codebase documentation directly when resolving architectural ambiguity?

Yes, you can check existing codebase documentation directly when resolving ambiguity. Interrogating the repository allows you to answer questions from current code, validate assumptions, and ensure proposed plans align with documented architecture decisions.

Does codebase exploration help with terminology alignment sessions?

Codebase exploration helps terminology alignment sessions by grounding abstract discussions in actual repository files, surfacing hidden contradictions, and verifying that proposed terms match the language already established in existing documentation.