| name | requirements-grilling |
| description | Use after legacy-discovery and before any design or build to adversarially interrogate requirements — challenge assumptions, sharpen terminology, resolve ambiguity one question at a time until requirements are crisp. Matt Pocock style grilling. Acts as a gate. |
Requirements Grilling
Adversarial requirement interrogation. Your job is to attack vague requirements
until they are crisp, not to be agreeable. A requirement that can be read two
ways is a bug waiting to happen. This skill is a gate: design does not start
while ambiguity remains.
When to use
- After
legacy-discovery and architecture-recovery, before
ux-modernization / strangler-backend design.
- Whenever a requirement, term, or acceptance criterion — functional or
architectural — is fuzzy.
Method (Matt Pocock style)
Grill one question at a time. After each answer, either drill deeper or mark
the item resolved. Do not batch questions.
For every requirement and every open question from discovery and
architecture-recovery, interrogate:
- Define the term. "메시지 검토" — what exactly, by whom, with what pass/fail
rule? Nail terminology; build a glossary. Reject undefined nouns.
- Challenge the assumption. "Why is this a separate screen? What breaks if it
isn't?" Surface implicit constraints.
- Force the acceptance criterion. "How will we know this is done and
correct?" Every requirement needs a testable criterion — these become the
inputs to
behavior-harness and test-authoring.
- Probe the edge cases. Bulk send, failure/delay, concurrent approval,
partial send. What is the expected behavior for each?
- Grill the target architecture against as-is reality. Take the target
constraints and candidate directions from
architecture-recovery and attack
them: "This to-be design assumes event-driven status — does the current engine
refactor actually expose that seam? What does the DB2DB link cost to migrate?
Which constraint makes this option infeasible?" A to-be architecture requirement
that ignores an as-is constraint is a fantasy — force it to be grounded.
- Confirm scope boundary. In or out for this goal level (30/60/100)? Kill
gold-plating (YAGNI).
Output
Update/create docs/renovation/03-requirements.md:
# Requirements: <system>
## Glossary (term → precise definition)
## Requirements (id | statement | acceptance criterion | edge cases | scope 30/60/100)
## Target architecture (decision | chosen option | as-is constraint it respects | rejected alternatives)
## Assumptions killed (assumption → resolution)
## Still ambiguous (MUST be empty to pass the gate)
Gate rule
The grilling gate passes only when "Still ambiguous" is empty and every
in-scope requirement has a testable acceptance criterion. Report gate status back
to renovate-orchestrator.
Transition
On pass → behavior-harness (turn acceptance criteria into characterization
tests before any code changes).
Output template and helper script
- Korean template: OUTPUT_TEMPLATE.md
- Scaffold script:
scripts/create-requirements.sh <repo-root> <target-name>
