Requirements Writing.instructions

---
description: "Use when writing PRDs, feature requirements, or acceptance criteria in markdown. Enforces consistent wording, requirement IDs, and acceptance style."
name: "Requirements Writing Standards"
applyTo: "tasks/**/*.md|project-tasks/**/*.md|docs/tasks/**/*.md|.github/tasks/**/*.md"
---

# Requirements Writing Standards

## Purpose

Write clear, testable, and consistent product requirements and acceptance criteria.

## Requirement Wording Rules

- Use consistent requirement IDs:
  - Functional: `FR-1`, `FR-2`, ...
  - Non-functional: `NFR-1`, `NFR-2`, ...
  - Acceptance: `AC-1`, `AC-2`, ...
- Use normative language consistently:
  - `SHALL` for mandatory behavior
  - `SHOULD` for recommended behavior
  - `MAY` for optional behavior
- Preferred requirement sentence pattern:
  - `<ID>: <System or product> SHALL <observable outcome> [under <condition>]`
- Keep each requirement atomic:
  - One statement, one behavior
  - Split combined requirements into separate IDs
- Keep requirements outcome-focused:
  - State what must happen
  - Avoid implementation details (libraries, APIs, class names, algorithms)

## Ambiguity Guardrails

Avoid vague terms unless quantified:

- Avoid: `fast`, `intuitive`, `robust`, `user-friendly`, `as needed`
- Prefer: measurable thresholds, explicit conditions, concrete outcomes

## Acceptance Style

- Every `FR-*` should map to one or more `AC-*` items.
- Write acceptance criteria so they are objectively verifiable.
- Preferred style: Given/When/Then.

Acceptance criterion pattern:

- `AC-<n>: Given <context>, when <action/event>, then <expected observable result>.`

## Consistency Rules

- Use the same term for the same concept throughout the document.
- Keep actor names consistent (for example, `end user`, `admin`, `finance manager`).
- Keep tense and voice stable (present tense, active voice preferred).

## Definition of Done for Requirements Sections

A requirements section is complete only if:

- All requirements have unique IDs.
- Each requirement is specific and testable.
- Acceptance criteria exist for all major functional requirements.
- Success metrics are measurable and aligned to goals.
- Open questions are explicitly listed as `TBD` items.

## Quick Example

- Weak: `FR-2: The app should be fast and easy to use.`
- Strong: `FR-2: The product SHALL display the monthly budget summary within 2 seconds for 95% of requests under normal operating load.`