grill-with-docs

Interviews users about design decisions and records outcomes as documentation.

6|Updated Mar 10, 2026
One-click install
npx skills add https://github.com/northguild/gmt --skill grill-with-docs-northguild
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: grill-with-docs
Source: https://github.com/northguild/gmt/tree/main/.agents/skills/grill-with-docs
Command: npx skills add https://github.com/northguild/gmt --skill grill-with-docs-northguild

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Designs and plans often contain unexamined assumptions about inputs, timezones, DST behavior, and locale handling that surface as bugs later. This Skill stress-tests a plan through structured questioning while capturing every settled decision as written documentation. ## Core Features & Use Cases - Assumption Probing: Asks one question at a time about inputs, sentinels, plain vs zoned values, DST gaps, non-existent days, and locale behavior, forcing concrete input-to-output examples. - Conflict Detection: Checks each answer against decisions of record in AGENTS.md and coding-standards calendar/zone semantics, flagging contradictions instead of silently accepting them. - Decision Recording: Writes settled decisions to the story's context/domination/issues/<ID>.md file or the relevant project-wide context file, keeping entries short with decision, reason, and source. - Use Case: Before implementing a new date arithmetic feature in a Temporal-based library, run this interview to pin down DST disambiguation behavior and record the ruling where future agents will find it. ## Quick Start Ask the assistant to grill you on your current design or plan and document the decisions as you answer.

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 design before implementing it?▼

Run a structured interview that questions every assumption one at a time, forcing concrete input-to-expected-output examples. This Skill pushes on inputs, sentinels, timezone semantics, DST behavior, and locale handling until each decision is explicit.

How to document design decisions during a review session?▼

Record each settled decision as a short entry containing the decision, the reason, and the source. Epic-level work goes into the story's context/domination/issues/<ID>.md file, while project-wide rules go into the relevant context/ file.

What date and time edge cases should a design review cover?▼

Cover plain vs zoned value handling, DST transitions and non-existent days, locale-specific behavior, and sentinel or invalid inputs. Each answer should also be checked against what existing library functions already cover.

What happens when an answer conflicts with existing project rules?▼

The conflict is flagged explicitly instead of being silently recorded. Answers are checked against AGENTS.md core rules and the coding-standards calendar and zone semantics section before being accepted.

When should I not use an interview-style design review?▼

Avoid it for trivial changes with no ambiguity in inputs, timezones, or locale behavior, where the questioning overhead exceeds the risk. It is designed for plans with meaningful semantic decisions that future contributors must understand.