83 lines
3.6 KiB
Markdown
83 lines
3.6 KiB
Markdown
|
---
|
||
|
|
name: grill
|
||
|
|
description: >
|
||
|
|
Calibrated interrogation to stress-test a fuzzy plan, design, or architecture before writing a spec or code.
|
||
|
|
Asks one question at a time with recommended answers to extract concrete goals (§G) and constraints (§C).
|
||
|
|
Use when asked to "grill me", "stress-test this", "challenge my plan", or before authoring a spec.
|
||
|
|
concerns: [system-one-balance]
|
||
|
|
---
|
||
|
|
|
||
|
|
# Grill — Calibrated Plan Stress-Testing
|
||
|
|
|
||
|
|
Drags ambiguity into concrete goals (§G) and constraints (§C) *before* execution begins. A bad assumption caught here costs one question; caught later, it costs an architectural refactor.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Phase 0: Setup and Protocols
|
||
|
|
|
||
|
|
1. **Interrogation Invariants**:
|
||
|
|
- **One Question at a Time**: Never ask multiple questions in a single turn. Ask one question, provide a recommended answer, and wait.
|
||
|
|
- **Recommend an Answer**: Always provide a concrete default so the user can reply with "yes" or choose an alternative.
|
||
|
|
- **Inspect Context First**: If an answer can be found in files, code, docs, or git history, inspect them directly instead of asking the user.
|
||
|
|
- **Propose, Don't Decide**: Challenge tradeoffs and surface hidden edge cases, but leave final product choices to the user.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Phase 1: Ingest and Check
|
||
|
|
|
||
|
|
1. Determine user knowledge and desired pressure level from context:
|
||
|
|
- **Knowledge Level**:
|
||
|
|
- *New*: Explain missing frames briefly (2 sentences); focus on first principles and goals.
|
||
|
|
- *Working*: Challenge standard tradeoffs, alternatives, and validation criteria.
|
||
|
|
- *Expert*: Probe failure modes, boundary limits, migration costs, and reversibility.
|
||
|
|
- **Pressure Level**:
|
||
|
|
- *Light*: Clarify goals, scope, and missing definitions.
|
||
|
|
- *Standard*: Challenge assumptions, resource bottlenecks, and execution paths.
|
||
|
|
- *Hard*: Probe edge cases, adverse incentives, failure modes, and rollback mechanisms.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Phase 2: Processing (Core Logic)
|
||
|
|
|
||
|
|
Climb the Question Ladder in sequence. Stop as soon as the plan is clear; do not ask every rung by reflex:
|
||
|
|
1. **Goal (§G)**: What must the code or feature accomplish in one single, unambiguous sentence?
|
||
|
|
2. **Done Criteria (§C / §V)**: What observable signal (test, metric, terminal output) proves this works?
|
||
|
|
3. **Boundaries (§C)**: What is explicitly *out of scope* for this change?
|
||
|
|
4. **Non-Negotiables (§C)**: What architectural patterns, libraries, or constraints are strictly required or forbidden?
|
||
|
|
5. **Surfaces (§I)**: What external membranes (API endpoints, CLI flags, DB tables, schemas) will be modified?
|
||
|
|
6. **Failure Modes (§V)**: What is the primary edge case or input that breaks the happy path?
|
||
|
|
7. **Unknowns (`?`)**: What do we not yet know? (Park unresolved items as `?` bullets; do not guess them).
|
||
|
|
|
||
|
|
### Question Format
|
||
|
|
```text
|
||
|
|
Question: ...
|
||
|
|
Recommended answer: ...
|
||
|
|
Why it matters: [1 sentence rationale]
|
||
|
|
```
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Phase 3: The System One Balance Pass
|
||
|
|
|
||
|
|
- **Augment, Don't Handcuff**:
|
||
|
|
- Stop grilling immediately once the goal and boundaries are defined.
|
||
|
|
- Never interrogate the user on routine file edits, typo fixes, or straightforward tasks.
|
||
|
|
- Accept the user's recommended answer or override without debate.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Phase 4: Output Execution & Verification
|
||
|
|
|
||
|
|
Stop grilling when **all** of the following hold:
|
||
|
|
- §G is one line, one reading, zero "or maybe".
|
||
|
|
- §C covers every non-negotiable stated or implied.
|
||
|
|
- Every blocking unknown is answered or parked as an explicit `?`.
|
||
|
|
|
||
|
|
Emit the structured handoff block to pass to the **spec** or **build** workflow:
|
||
|
|
```markdown
|
||
|
|
## Grill Handoff
|
||
|
|
- **§G**: [One-line goal]
|
||
|
|
- **§C**: [Constraints and non-negotiables]
|
||
|
|
- **§I**: [Surfaces touched]
|
||
|
|
- **Parked Unknowns (`?`)**: [Items deferred to research]
|
||
|
|
```
|