How do I install the Requirements Grill skill?

Run npx skillmds@latest add z-cursor/requirements-grill in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Requirements Grill safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Requirements Grill?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Requirements Grill free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Requirements Grill?

z-cursor (@z-cursor) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Requirements Grill by z-cursor — Agent Skill

Name: Requirements Grill
Author: z-cursor

File contents

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:

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

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

---name: requirements-grilldescription: 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.---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.## CoverageThe 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## ClassificationClassify 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 hereA 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.## BoundariesDecide: 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.## CompletionThe 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 requirementDeferred questions are marked DEFERRED. They do not silently disappear.## HandoverWrite 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.

Frequently asked questions

Requirements Grill