authoring-requirements

# Authoring Requirements ## Overview Write technology-agnostic functional requirements, identify edge cases, and define measurable success criteria. Focus on WHAT the system does and WHY, never HOW it's implemented. ## When to Use - Starting a new feature specification - Documenting acceptance criteria for user stories - Defining API contracts at the business logic level - Creating requirements for stakeholder review - When existing requirements are vague or missing structure - Translating informal feature requests into formal requirements ## When NOT to Use - **Implementation planning** - Use design docs or architecture decisions instead - **Technical architecture decisions** - Use ADRs or technical design documents - **When requirements already exist and are validated** - Don't duplicate work - **API endpoint specifications** - Use `humaninloop:patterns-api-contracts` instead - **Data model design** - Use `humaninloop:patterns-entity-modeling` instead - **User story authoring** - Use `humaninloop:authoring-user-stories` instead (this skill focuses on the underlying requirements) ## Functional Requirements Format Write requirements using the FR-XXX format with RFC 2119 keywords: ```markdown ## Functional Requirements - **FR-001**: System MUST [specific capability] - **FR-002**: Users MUST be able to [specific action] - **FR-003**: System SHOULD [recommended behavior] - **FR-004**: System MAY [optional capability] ``` ### RFC 2119 Keywords | Keyword | Meaning | |-...