skills.rest
NestorMonroy
NestorMonroyCOMMUNITY
Explore all skills by this author →
GitHub

rm-specification

Formalize analyzed requirements into specification documents with acceptance criteria and traceability.

1|Updated Mar 25, 2026
Search Tags:#acceptance criteria#user stories#traceability#requirements management#gherkin#ieee 830#requirements specification
One-click install
npx skills add https://github.com/NestorMonroy/thyrox --skill rm-specification-nestormonroy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: rm-specification
Source: https://github.com/NestorMonroy/thyrox/tree/main/.claude/skills/rm-specification
Command: npx skills add https://github.com/NestorMonroy/thyrox --skill rm-specification-nestormonroy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes assets (resource) and references (resource) components.

What problem does it solve? Turning analyzed requirements into a formal, verifiable specification is error-prone: requirements without acceptance criteria cannot be tested, and without a signed baseline there is no change control. This Skill guides the Specification step of the Requirements Management cycle, producing standard-format documents (IEEE 830 SRS, BRD, or User Stories) with verifiable acceptance criteria and full traceability. ## Core Features & Use Cases - Format Selection Guidance: Decision criteria for choosing between IEEE 830 SRS, BRD, User Stories with Given/When/Then, or hybrid formats based on contract type, audience, and project context. - Quality Frameworks Built In: INVEST validation for User Stories, Gherkin/BDD acceptance criteria patterns, and quantitative NFR specification templates for performance, security, availability, and usability. - Baseline & Traceability: Establishes a versioned requirements baseline with stakeholder sign-off and requirement-to-stakeholder traceability matrices. - Use Case: After completing requirements analysis with MoSCoW prioritization, use this Skill to produce an rm-specification.md document where every requirement has a unique ID, priority, origin, and testable acceptance criterion, ready for validation and change management. ## Quick Start Ask the AI to formalize the analyzed requirements in rm-analysis.md into a specification document with acceptance criteria and a traceability matrix.

Frequently Asked Questions about rm-specification

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a requirements specification document?▼

Start from analyzed, prioritized requirements, choose a format (IEEE 830 SRS for formal contracts, BRD for business projects, User Stories for agile teams), then give each requirement a unique ID, priority, origin, and a testable acceptance criterion. Finish by establishing a versioned baseline with stakeholder sign-off.

What is the difference between IEEE 830 SRS and User Stories?▼

IEEE 830 SRS is a formal, exhaustive standard suited to regulated or contractual projects, while User Stories are lightweight, value-oriented units for agile teams. User Stories require explicit acceptance criteria (Given/When/Then) and INVEST validation to remain testable.

How do I write acceptance criteria with Given/When/Then?▼

Use the Gherkin pattern: Given states the precondition, When describes the user action, and Then states the observable result. Each story needs at least one happy-path scenario and one error scenario, avoiding implementation details like button labels or API endpoints.

How do I specify non-functional requirements like performance?▼

Write NFRs with quantitative metrics and verification methods, for example p95 response time under 500ms at 100 concurrent users verified by load testing. Vague statements like 'the system must be fast' are not specifiable or testable.

When should I not create a requirements specification?▼

Do not specify before analysis is complete with quality checks passed and conflicts resolved. Specifying unverified requirements propagates defects into design, development, and testing artifacts.

What is a requirements baseline and why does it matter?▼

A baseline is the formally approved, versioned specification (v1.0) signed off by the sponsor or product owner. Without it, later changes have no formal reference point, making change control impossible.

Related Skills

Explore More Product & Management Skills→
AlteriomAlteriom

requirements-analysis

Analyze and document software requirements using IEEE 830 and BABOK standards.

Official
Advanced
devmuslimdevmuslim

change-request

Generate a formal change request document for project scope, timeline, or budget changes.

Community
Intermediate
4797pnkkx5-gif4797pnkkx5-gif

trace

Generate a project-wide requirements traceability matrix from pipeline artefacts.

Community
Advanced
AbsolutelySkilledAbsolutelySkilled
207

user-stories

Generate user stories and acceptance criteria using INVEST and Given/When/Then templates.

Official
Advanced