Requirements grill

Skill willianbs/skills/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.From its SKILL.md

Install

npx -y skills add willianbs/skills --skill requirements-grill

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.7 KB, 562 tokens by cl100k_base, as published. Nobody here has run it

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

Adversarial but respectful — attack ambiguity, not people.
Prefer questions that unlock decisions over essays.
Surface hidden assumptions, non-goals, and edge cases.
Force measurable acceptance criteria candidates.
Separate ProductDecisionNeeded vs EngineeringDecisionNeeded.
Cap to the smallest question set that unblocks Ready.
Do not silently fill gaps.

Process

Restate the ask in one sentence; confirm.
Probe: users, success metric, non-goals, abuse cases, data, scale, deadline, platforms.
Contradiction hunt — flag conflicts.
Edge-case battery — empty, failure, permissions, concurrency, migration.
Draft candidate AC IDs (provisional) for spec-validator.
List blocking questions vs nice-to-have.
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.

What ships with it: 1 file

730 B alongside SKILL.md

README.md730 B