grill-me

name	grill-me
description	Stress-test EDHB ExecPlans and implementation proposals through focused questioning before milestones are locked or code starts. Use when Codex is creating, revising, or materially expanding an ExecPlan; when a feature proposal has architectural, validation, UI, durability, or maintainability uncertainty; or when the user explicitly asks to grill, challenge, interview, or pressure-test a plan.

Grill Me

Purpose

Use this skill to pressure-test a proposed EDHB plan before implementation. The goal is a shared, concrete understanding of scope, risks, validation, documentation, and follow-up boundaries, not a long generic questionnaire.

Workflow

1. Read the relevant issue, request, current ExecPlan if one exists, PLANS.md, and the root control docs that govern the change.
2. Inspect the codebase first for answers that are already knowable from files, tests, or existing plans. Do not ask the user questions that quick repository discovery can answer.
3. Build a short decision tree of unresolved plan choices. Prioritize questions that can change architecture, file ownership, user-visible behavior, validation evidence, migration path, or whether work should be split.
4. Ask one question at a time. Include your recommended answer and the tradeoff it accepts. Prefer concrete options over open-ended prompts when options are clear.
5. After each answer, update the plan direction or ask the next blocking question. Stop grilling when remaining questions would not materially change the ExecPlan.
6. Record resolved decisions in the ExecPlan Decision Log, and make sure the milestone list reflects those decisions before seeking milestone approval.

Question Targets

Cover only targets that matter for the specific plan:

• user-visible behavior and exact done criteria;
• backend/frontend ownership boundaries and public command or snapshot contracts;
• durable-doc updates for PRODUCT.md, ROADMAP.md, DESIGN.md, ARCHITECTURE.md, CODESTYLE.md, or AGENTS.md;
• validation commands, coverage comparison, line-count review, browser evidence, and screenshot review;
• UI mockup needs, visual states, responsive states, and approval checkpoints;
• migration, rollback, compatibility, or data-persistence risks;
• future feature pressure, context bloat, file-size risk, and likely follow-up work;
• issue or PR scope boundaries when several requests are bundled.

Output Style

Keep questions direct and answerable:

Question: Should the plan treat Campaign and normal runs as one shared flow?
Recommended: Yes. The current frontend starts both through `RunController`, so a split plan would duplicate validation and increase drift.
Tradeoff: Shared flow testing needs both Campaign and non-Campaign cases before completion.

If repository discovery answers a branch of the decision tree, state the finding and evidence instead of asking:

Answered from repo: UI mockups are not needed because this is a small copy-only change. Evidence: `PLANS.md` limits `.agents/skills/ui-mockups/SKILL.md` to substantial UI additions, refactors, responsive changes, or design-direction choices.

Avoid broad prompts like "any other requirements?" unless every concrete blocking question has already been resolved.