Generate Comprehensive Technical Specifications

This is a technical-specification-writing skill that structures a spec document into five sections - Executive Summary, System Overview, Detailed Requirements (functional, non-functional, constraints and assumptions), Technical Design (architecture, data models, API specs, security), and an Implementation Plan (phases, dependencies and risks, testing strategy). Requirements are written with unique IDs and MoSCoW prioritization:

### FR-001: User Authentication [MUST HAVE]
**Description**: Users must authenticate using OAuth 2.0
**Acceptance Criteria**:
- Support Google, GitHub, and Microsoft SSO
- Session timeout after 24 hours
- Failed login attempts locked after 5 tries
**Dependencies**: OAuth service configuration
**Effort**: 5 story points

APIs are specified in OpenAPI 3.0 format with example request and response bodies, data models are documented as SQL DDL with explicit constraints and indexes, and major technical decisions get an Architecture Decision Record with status, context, decision, rationale, and consequences split into positive, negative, and risk.

Use this skill when writing a definitive spec that development teams, architects, and stakeholders will actually implement against - it names concrete standards to hold requirements, APIs, and data models to: OpenAPI 3.0 for API contracts, explicit database constraints and indexing strategy for data models, and specific security requirements (JWT with RS256 signing, 1-hour access and 7-day refresh token expiration, AES-256 encryption at rest, TLS 1.3+ in transit) rather than vague security language. It also sets concrete testing and delivery gates - 80%+ unit test coverage, phase-based delivery with explicit acceptance criteria and risk mitigation - and treats the spec itself as a living document with monthly review cycles and stakeholder sign-off. It is not a lightweight requirements doc - the structure assumes a full implementation blueprint, so it isn't the right fit for a quick one-pager or an early-stage exploratory proposal.

Input is the project's requirements, architecture decisions, and constraints; output is a structured specification document: prioritized functional and non-functional requirements with acceptance criteria and effort estimates, an OpenAPI-format API specification, SQL schema definitions with constraints and indexes, Architecture Decision Records for major choices (e.g. selecting PostgreSQL 15+ with read replicas for ACID compliance and JSON support), a phased implementation timeline with deliverables and acceptance criteria per phase, named compliance requirements (GDPR right-to-deletion and data portability, SOC 2 Type II audit logging, PCI DSS where payment data is handled), and a testing strategy spanning unit, integration, performance, security, and user-acceptance tests.

References OpenAPI 3.0 for API documentation, standard SQL DDL for data models, and named compliance frameworks - GDPR, SOC 2 Type II, PCI DSS - as the security and compliance baseline.

Technical leads, architects, and product teams producing an implementation-ready specification who want a consistent structure for requirements, API contracts, data models, ADRs, security, and phased delivery, rather than an ad hoc requirements document.