requirements-grilling

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:

1. Define the term. "메시지 검토" — what exactly, by whom, with what pass/fail rule? Nail terminology; build a glossary. Reject undefined nouns.
2. Challenge the assumption. "Why is this a separate screen? What breaks if it isn't?" Surface implicit constraints.
3. 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.
4. Probe the edge cases. Bulk send, failure/delay, concurrent approval, partial send. What is the expected behavior for each?
5. 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.
6. 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>