spec-authoring

Specification Authoring Skill

Creates properly structured ADR, PRD, and SDS documents with full traceability.

Document Types

ADR (Architecture Decision Record)

Purpose: Capture architecture decisions with context, options, and consequences.

Template Fields:

• ADR-ID (e.g., ADR-031)
• Status (Proposed, Accepted, Deprecated)
• Context & Problem Statement
• Decision Drivers
• Considered Options
• Decision Outcome
• Consequences (positive, negative, neutral)
• Links to follow-up PRDs/SDS

PRD (Product Requirement Document)

Purpose: Define product requirements and acceptance criteria.

Template Fields:

• PRD-ID (e.g., PRD-020)
• Problem Statement
• User Stories (EARS format)
• Functional Requirements (FR-###)
• Non-Functional Requirements (NFR-###)
• Acceptance Criteria
• Traceability to ADRs

SDS (Software Design Specification)

Purpose: Detailed technical design with SEA-DSL flows.

Format: YAML frontmatter + Markdown content

Template Fields:

• SDS-ID (e.g., SDS-045)
• Bounded Context
• Service/Component name
• Implements (ADR/PRD references)
• SEA-DSL specification
• API contracts
• Invariants

Traceability Chain

ADR → PRD → SDS → SEA-DSL → Generated Code

Each document MUST reference its upstream documents:

• SDS must reference PRD and/or ADR it implements
• PRD must reference ADR it satisfies

Workflow

1. Identify what decision/requirement/design to document
2. Choose appropriate document type (ADR/PRD/SDS)
3. Use /spec workflow to create from template
4. Fill in all required fields
5. Add traceability links
6. Validate with just spec-guard

File Locations

Related Skills

• sea-dsl-authoring
• governance-validation