skills.rest
OrestesK
OrestesKCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

grill-with-docs

Stress-test implementation plans against codebase, domain terminology, and architectural decisions.

2|Updated May 5, 2026
Search Tags:#domain modeling#adr#codebase exploration#architectural decisions#plan review#context glossary
One-click install
npx skills add https://github.com/OrestesK/pi --skill grill-with-docs-orestesk
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/OrestesK/pi/tree/main/packages/context-mode/skills/grill-with-docs
Command: npx skills add https://github.com/OrestesK/pi --skill grill-with-docs-orestesk

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill prevents design plans from drifting away from the existing codebase, domain language, and documented architectural decisions.

Core Features & Use Cases

  • Relentless Plan Review: Explore each branch of a proposed design and ask focused questions one at a time.
  • Domain Alignment: Detect ambiguous or conflicting terminology and sharpen it into a shared project vocabulary.
  • Documentation Updates: Capture resolved terms in CONTEXT.md and record only significant, hard-to-reverse decisions as ADRs.
  • Use Case: Use it before implementing a major feature to verify that the plan matches the code, clarify domain boundaries, and preserve important decisions for future contributors.

Quick Start

Use the grill-with-docs skill to challenge my implementation plan against the codebase, existing domain glossary, and architectural decisions.

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 implementation plan against my existing codebase?▼

To stress-test an implementation plan against your codebase, iteratively explore each branch of the proposed design and ask focused questions to verify it aligns with existing code, domain terminology, and documented architectural decisions.

When do I need to document architectural decisions as ADRs?▼

You need to document architectural decisions as ADRs only for significant, difficult-to-reverse trade-offs identified during design reviews, preserving important context for future contributors without cluttering documentation with minor choices.

How do I align domain terminology and resolve ambiguous definitions during feature planning?▼

Align domain terminology by detecting ambiguous or conflicting definitions during plan review, sharpening them into a shared project vocabulary, and capturing resolved terms inline within a CONTEXT.md file.

Can I review architectural changes by exploring each branch of a proposed design?▼

Yes, you can review architectural changes by exploring each branch of a proposed design one at a time, applying iterative questioning to ensure the plan matches the code and domain boundaries.

What is the best way to prevent design plans from drifting away from the codebase?▼

The best way to prevent design plan drift is to challenge the proposed implementation against the existing codebase, domain glossary, and documented architectural decisions through relentless, iterative plan review.

Related Skills

Explore More Software Engineering Skills→
aurora-atomsaurora-atoms

reviewer-rehearsal

Identify design risks and missing evidence in software changes for formal review.

Community
Advanced
brunolimaff-jpgbrunolimaff-jpg

super-brainstorm

Convert feature ideas into validated design specifications before implementation.

Community
Advanced
SwitchbackTechSwitchbackTech
228

grill-with-docs

Grill a plan against the repository's domain model to surface ambiguities.

Official
Advanced
OmarMiraOmarMira

architecture

Guide architectural decision-making with requirements analysis and ADR documentation.

Community
Intermediate