mcpField
G
grill-with-docs

grill-with-docs

github.com/wilbeibiDevelopment235 installsUpdated 2d ago
Repository

About grill-with-docs

A documentation-oriented skill that interviews users one question at a time to clarify plans, terminology, and decisions. It checks existing project context and documentation before asking or proposing new files.

Key features

  1. 01One focused question at a time
  2. 02Inspect existing project documentation
  3. 03Surface assumptions and tradeoffs
  4. 04Update context after terminology is settled
  5. 05Create ADRs selectively

Use cases

  1. 01Clarifying an implementation plan before work
  2. 02Resolving project-specific terminology
  3. 03Evaluating whether a decision needs an ADR

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/wilbeibi/wilbeibi-skills --skill grill-with-docs

After installing, type/grill-with-docsin Claude Code to confirm it loaded.

Bundled filesADR-FORMAT.mdCONTEXT-FORMAT.md

Details

From the project README

grill-with-docs

Interview the user one question at a time until the plan, terminology, and important decisions are clear enough to act on.

Workflow

  1. Read the user's plan, linked docs, code, or local files needed to understand the topic.
  2. Look for existing CONTEXT.md, CONTEXT-MAP.md, and docs/adr/ files before proposing new docs.
  3. Ask one focused question at a time. Wait for the answer before continuing.
  4. If the answer can be discovered from the codebase or existing docs, inspect those instead of asking.
  5. For each question, include your recommended answer or likely tradeoff so the user can accept, reject, or refine it.
  6. Push on fuzzy words, hidden assumptions, edge cases, dependencies between decisions, and reversibility.
  7. When terminology is resolved, update the appropriate CONTEXT.md immediately.
  8. Offer an ADR only for decisions that are hard to reverse, surprising without context, and based on a real tradeoff.

Documentation Rules

  • CONTEXT.md is a glossary and relationship map for project-specific language, not a spec or scratchpad.
  • Use CONTEXT-MAP.md only when the repository has multiple bounded contexts.
  • Create documentation lazily: do not add CONTEXT.md or docs/adr/ until there is real resolved content.
  • Keep docs concise enough that future agents will actually read them.

For glossary format, read CONTEXT-FORMAT.md. For ADR format and thresholds, read ADR-FORMAT.md.

Question Patterns

  • "What outcome would make this change a success?"
  • "Which existing concept owns this behavior?"
  • "What is the smallest scenario that proves the design works?"
  • "What breaks if this assumption is false?"
  • "What would a future maintainer be tempted to change back?"
  • "Which term should be canonical, and which aliases should be avoided?"

Comments

Markdown supported