grillme

Validate implementation plans against domain glossary and ADR history.

4|3|Updated May 2, 2026
One-click install
npx skills add https://github.com/ggemba/squad-mcp --skill grillme
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grillme
Source: https://github.com/ggemba/squad-mcp/tree/main/skills/grillme
Command: npx skills add https://github.com/ggemba/squad-mcp --skill grillme

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents costly misunderstandings by interrogating your proposed plan against the repository’s domain language and prior decisions before implementation.

Core Features & Use Cases

  • Socratic one-question validation: Asks a single targeted question at a time to surface terminology drift, hidden assumptions, and missing decisions.
  • Domain-aligned glossary resolution: Resolves ambiguous or conflicting terms by updating CONTEXT.md (or flagging ambiguity when appropriate).
  • ADR offers when warranted: Proposes an Architecture Decision Record only when the decision is hard to reverse, surprising without context, and reflects a real trade-off with rejected alternatives.
  • Read/write guardrails with dry-run: Applies updates only with explicit per-write confirmation and supports --no-write dry-run patch emission.

Quick Start

Use the grillme skill by telling it: /squad:grillme --normal "Store user notifications in a separate table and query them per user to show alerts in the UI".

Frequently Asked Questions about grillme

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

FAQPage Schema
How do I validate a software design plan against domain terminology before coding?

You validate a design plan by running a Socratic, one-question-at-a-time interview against the repository's domain glossary and ADR history, surfacing terminology drift, hidden assumptions, and missing decisions prior to implementation.

What is a Socratic review for architecture decision proposals?

A Socratic review is an interactive questioning process that probes a tactical or architectural design proposal one question at a time, checking it for consistency against documented domain truth and prior architecture decisions to prevent costly misunderstandings.

How do I check if my implementation plan conflicts with existing ADRs and bounded contexts?

You check for conflicts by scoping the review to a bounded context via CONTEXT-MAP.md and probing the existing CONTEXT.md and docs/adr/ directory, asking targeted questions to identify missing decisions or terminology drift in the proposed plan.

Can I dry-run a plan validation without writing changes to my repository files?

Yes, you can use a --no-write dry-run mode to emit proposed patch updates to CONTEXT.md without applying them, as all constrained file writing is gated behind explicit per-write confirmation for safe read-only probing.

When should I create a new Architecture Decision Record for a design proposal?

You should create a new ADR when the plan validation surfaces a decision that is hard to reverse, surprising without context, and reflects a real trade-off with rejected alternatives, ensuring the architectural choice is properly documented.

What are the limitations of automated domain glossary validation?

Validation is limited by the read-only probing of existing CONTEXT.md, CONTEXT-MAP.md, and docs/adr/ files, meaning it cannot validate plans effectively if the repository lacks prior domain documentation or established architectural decision records.