Requirements

Instructions

Create or update the requirements catalog at docs/requirements.md based on docs/vision.md. The document contains functional requirements, non-functional requirements, and constraints organized as Markdown tables. Alongside it, create or update the glossary at docs/glossary.md (see Glossary).

DO NOT

• Mix requirement types in a single table
• Skip the user story format for functional requirements
• Use duplicate IDs across requirement types
• Leave the Status column empty

Requirement Types

Functional Requirements (FR)

Define what the system should do. Always use the user story format:

Format: As a [role], I want [goal] so that [benefit].

Non-Functional Requirements (NFR)

Define quality attributes. Must be measurable.

Constraints (C)

Define limitations and boundaries imposed on the solution.

The Source column is optional — omit it when no constraint comes from an outside document. It names where a constraint comes from — a law, regulation, standard, or internal policy, down to the article or paragraph and, where it matters, the version (GDPR Art. 17(1), ISO 27001:2022 A.8.24, Operating Policy OP-12 v3) — so the origin of a mandated rule stays traceable. When the column is present, fill it for every Regulatory constraint and leave it empty for the others. Keep Status the last column.

Glossary

The glossary fixes one name per domain concept, so requirements, use cases, test cases, and code all use the same word. Use references/glossary.md as the structure (the path is relative to the folder containing this SKILL.md): one table with the columns Term | Definition | Avoid.

• Term — the preferred name, in singular, as the business says it. One row per concept; never define a term twice.
• Definition — one or two sentences that tell this concept apart from its neighbors (a Guest is not necessarily the person who made the Reservation).
• Avoid — comma-separated synonyms that must not be used for this concept, or empty. Only list a word here when it would be ambiguous or misleading; a word listed here is flagged wherever it appears in the specifications.

Take the terms from the vision and from the nouns of the user stories: roles, business objects, states, and business events. Leave out generic words (system, data, user interface). When the glossary already exists, add new terms and keep existing rows unless the user asks to change them.

Reference

See references/REFERENCE.md for ID prefixes, priority levels, status values, NFR categories, and constraint categories. The path is relative to the folder containing this SKILL.md, not to the project root.

Requirement Quality Checks

Every requirement must pass these checks before finalizing:

Error Recovery

• Incomplete source document: List what is missing (roles, NFR categories, constraints) and ask the user to clarify before proceeding
• Ambiguous requirement from user: Rewrite it as a measurable requirement and ask the user to confirm the threshold
• Conflicting requirements: Flag the conflict explicitly (e.g., "FR-003 requires real-time sync but C-002 limits to batch processing") and ask the user to resolve
• Missing stakeholder roles: Default to generic roles (User, Admin, System) and note them for user review

Format survives error recovery. Ambiguity, conflict, and provisional status never justify abandoning the user-story form. Every FR row — even one you are flagging as conflicting or unconfirmed — must still read "As a [role], I want [goal] so that [benefit]." Record the issue in a note or in the Status column (e.g., Conflict, Needs review); never by dropping the requirement to a flat statement like "Support real-time sync."

Workflow

1. Read the vision document or project brief
2. Use TodoWrite to create tasks for each requirement type
3. Write the document header
4. For functional requirements:
   • Identify user roles
   • Define user stories with clear goals and benefits
   • Assign priorities based on business value
5. For non-functional requirements:
   • Define measurable quality attributes
   • Categorize by NFR type
   • Ensure requirements are testable
6. For constraints:
   • Document technical and business limitations
   • Categorize by constraint type
   • Name the source of each regulatory or externally imposed constraint in the Source column
7. Validate: run every requirement against the quality checks table above
   • No duplicate IDs across all tables
   • All Status columns filled
   • Hard gate: every FR User Story matches "As a [role], I want [goal] so that [benefit]" — scan each row; any row missing "As a", "I want", or "so that" is rejected and rewritten before finalizing, no exceptions
   • All NFRs contain a measurable threshold
8. When updating an existing catalog whose use cases exist, set the progress status of each requirement (Open, In Progress, Implemented, Verified) from the **Status:** of the use cases that link it, as defined under Status in the reference; never change a Deferred or Rejected status on your own
9. Create or update docs/glossary.md with the domain terms used in the catalog, and use exactly those terms (never an Avoid synonym) in every requirement
10. Mark todos complete