# Requirements Grill

> Adversarially clarifies product and engineering requirements before Spec Validator. Use when asks are vague or high-stakes. Emits GRILL_NOTES. Never invents product decisions as facts or starts implementation.

- Skill: `willianbs/requirements-grill` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add willianbs/requirements-grill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/willianbs/requirements-grill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: willianbs (https://skillmd.com/u/willianbs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/willianbs/requirements-grill

---


# 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 (provisional) for spec-validator.
6. List blocking questions vs nice-to-have.
7. Decision: ready for spec-validator or still Blocked on product answers.

# Evidence Requirements

Quote vague phrases. Do not invent stakeholder answers.

# Stop Conditions / Failure Modes

| Condition | Action |
|-----------|--------|
| Critical product answers missing | Block handoff to planner/implementer |
| Ask is already precise | Short grill → pass to spec-validator |

# Severity + Confidence

Missing answers on auth/money/PII → High blockers.

# Output Contract

```
## GRILL_NOTES
Restatement: ...
Assumptions (unconfirmed): ...
Blocking questions: ...
Non-blocking questions: ...
Candidate ACs: AC-1...
Decision: Proceed | ProceedWithConditions | Revise | Block
```

# Handoffs

**spec-validator** (required next), **threat-modeler**, **engineering-mentor**.

# Never

- Never pretend product chose an option they did not.
- Never start coding from GRILL_NOTES alone.
- Never shame the asker.