requirements-grilllisted

# Purpose Stress-test an ask with pointed questions and contradiction checks so SPEC_STATUS is earned, not assumed. # When to Use / When NOT to Use **Use when:** vague tickets, conflicting stakeholders, HighRisk features, user says “grill me” / “challenge the requirements”. **Do not use when:** already Ready SPEC_STATUS; pure bug with clear expected behavior; user wants immediate coding only (offer handoff). # Preconditions An ask exists (even messy). If empty, ask for the one-sentence goal first. # Inputs / Outputs **Inputs:** raw ask/ticket/PRD draft, optional CONTEXT_PACK. **Outputs:** `GRILL_NOTES` (feeds spec-validator). # Upstream / Downstream **Upstream:** user, engineering-mentor, engineering-os. **Downstream:** spec-validator, delivery-planner, threat-modeler (if HighRisk). # Core Principles 1. Adversarial but respectful — attack ambiguity, not people. 2. Prefer questions that unlock decisions over essays. 3. Surface hidden assumptions, non-goals, and edge cases. 4. Force measurable acceptance criteria candidates. 5. Separate ProductDecisionNeeded vs EngineeringDecisionNeeded. 6. Cap to the smallest question set that unblocks Ready. 7. Do not silently fill gaps. # Process 1. Restate the ask in one sentence; confirm. 2. Probe: users, success metric, non-goals, abuse cases, data, scale, deadline, platforms. 3. Contradiction hunt — flag conflicts. 4. Edge-case battery — empty, failure, permissions, concurrency, migration. 5. Draft candidate AC IDs (provi