mcpField
R
requirements

requirements

github.com/owainlewisOther42339 installsUpdated today
Repository

About requirements

A skill for drafting and maintaining a root `REQUIREMENTS.md` as a durable product document. It guides product-level requirements work and explicitly stops before implementation planning or coding.

Key features

  1. 01Guided requirements discovery
  2. 02Stable REQ-n identifiers
  3. 03Evidence and assumptions tracking
  4. 04Testable acceptance conditions
  5. 05Explicit open decisions

Use cases

  1. 01Creating initial product requirements
  2. 02Updating requirements as scope changes
  3. 03Identifying decisions that block architecture or delivery

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/owainlewis/blueprint --skill requirements

After installing, type/requirementsin Claude Code to confirm it loaded.

Bundled filesagents/openai.yaml

Details

From the project README

Requirements

Create or update root REQUIREMENTS.md. Describe the product, what it does, and its key features. Keep this as a long-running product document. Use /spec for one feature and /architecture for system technical decisions.

Process

  1. Read the request, repository instructions, existing requirements, and relevant evidence. Reuse decisions already made.
  2. Identify the users, problem, desired outcome, scope, and constraints. Separate stated needs from assumptions. Inspect the repo for facts; ask the user for missing product decisions that could change the result.
  3. Write the requirements using the shape below. Give each requirement a stable REQ-n ID. Never reuse or renumber existing IDs.
  4. Check that the requirements agree, cover relevant failure behavior, and can be tested. Record unresolved decisions and whether they block architecture or delivery.
  5. Stop with the document ready for human review. Do not design the implementation, plan tasks, or write code.

Document shape

  • Purpose and users: the problem, who has it, and the outcome they need.
  • User journey: when several capabilities need connecting, show one realistic path from the problem to the desired result.
  • Evidence and assumptions: link supplied research, feedback, or existing behavior that supports the problem. Label consequential assumptions and how to validate them. Do not invent evidence.
  • Key features and scope: the main capabilities, their value, and explicit non-goals.
  • Requirements: observable behavior, business rules, permissions, and user-visible failure and recovery. Define domain concepts when needed.
  • Constraints: required compatibility, security, privacy, operational, and performance limits. Use measurable thresholds when known; mark unknown targets as open decisions.
  • Acceptance: observable conditions for the system capabilities. Leave detailed feature scenarios and checks to its spec.
  • Success measures: how to judge value after delivery, when evidence supports a measure. Keep these separate from implementation acceptance.
  • Open decisions: each missing answer, recommended default when justified, and its effect on further work.

Use only sections that help define this product. Combine related points and omit sections that add no useful information.

Update this document when the product, key features, scope, or business rules change. Keep it current; preserve feature decision history in specs. Keep feature implementation detail in specs.

Keep implementation choices out of requirements. Include an imposed technology only as a stated constraint. Do not invent user research, targets, or business rules.

Return

Report the path, decisions made, and any blocking question.

Comments

Markdown supported