# Requirements Grill

> Elicit and lock down a requirement contract before any design or implementation. Use when starting a feature, when a requirement is unclear, or before architecture work.

- Skill: `z-cursor/requirements-grill` (Agent Skill)
- Install (CLI): `npx skillmds@latest add z-cursor/requirements-grill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/z-cursor/requirements-grill/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: z-cursor (https://skillmd.com/u/z-cursor)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/z-cursor/requirements-grill

---


Settle the requirement before anything is designed. The interview engine is /grilling: its design tree and frontier decide what to ask. This skill decides what the tree must cover, what counts as settled, and what the session hands over.

## Coverage

The tree must visit, for the change at hand:

- goal and non-goals
- current and desired observable behavior
- inputs and outputs, state transitions
- failure behavior, boundary behavior
- constraints and invariants
- compatibility requirements
- acceptance criteria

## Classification

Classify every fact as you go into one of six buckets:

- **USER FACT** — stated by the user
- **REPO FACT** — verified in the code or by running it
- **ASSUMPTION** — inferred, not yet verified
- **REQUIREMENT** — a confirmed product or business requirement
- **OPEN QUESTION** — not yet closed
- **ARCHITECTURE QUESTION** — a design problem that surfaced here

A repo fact is not a requirement. "The current system uses SessionStore" is a repo fact; "the new system must use SessionStore" is an architecture decision. The first gets recorded; the second, if it comes up, gets recorded as an ARCHITECTURE QUESTION.

## Boundaries

Decide: what the user actually needs, normal and edge behavior, compatibility, acceptance criteria.

Record, don't decide: module boundaries, state ownership, dependency direction, shared abstractions, persistence, migration. When a question lands there, write it down as an ARCHITECTURE QUESTION and move on.

## Completion

The session is done when:

- /grilling's frontier is empty
- every dimension above has been visited
- no blocking OPEN QUESTION remains
- assumptions are explicitly classified
- acceptance criteria are sufficient to test the requirement

Deferred questions are marked DEFERRED. They do not silently disappear.

## Handover

Write the requirement contract to a markdown file the user names. Give every requirement a stable ID — REQ-001, REQ-002 — and keep a ledger per requirement: source, status (`ANSWERED` / `REPO_VERIFIED` / `DEFERRED` / `NOT_APPLICABLE`), acceptance evidence, related architecture questions. The contract is the single handover to the architecture layer; if it gets compressed later, nothing settled here is lost.

Contract contents:

<contract-template>

## Goal

## Non-goals

## Current Behavior

## Desired Behavior

## User Facts

## Repo Facts

## Requirements

## Invariants

## Inputs

## Outputs

## Failure Behavior

## Boundary Behavior

## Compatibility Requirements

## Acceptance Criteria

## Open Questions

## Architecture Questions

</contract-template>

The contract stays free of design vocabulary — repository, service, manager, adapter — except where it describes existing code facts.