Feature specifications
System design documents
Requirements documentation (PRD)
Architecture decision records (ADR)
Technical proposals
RFC (Request for Comments)
API design specs
Database schema designs

Quick Start

Minimal working example:

# Technical Specification: [Feature Name]

**Document Status:** Draft | Review | Approved | Implemented
**Version:** 1.0
**Author:** John Doe
**Date:** 2025-01-15
**Reviewers:** Jane Smith, Bob Johnson
**Last Updated:** 2025-01-15

## Executive Summary

Brief 2-3 sentence overview of what this spec covers and why it's being built.

**Problem:** What problem are we solving?
**Solution:** High-level description of the solution
**Impact:** Expected business/user impact

---

## 1. Background

### Context

Provide background on why this feature is needed:

// ... (see reference guides for full implementation)

Reference Guides

Detailed implementations in the references/ directory:

Guide	Contents
Functional Requirements	Functional Requirements
Non-Functional Requirements	Non-Functional Requirements
Database Schema	Database Schema
API Data Models	API Data Models
Authentication Endpoints	Authentication Endpoints
Rate Limiting	Rate Limiting
Phase 1: Core Authentication	Phase 1: Core Authentication (Week 1-2), Phase 2: Email Verification (Week 3), Phase 3: Social Login (Week 4), Phase 4: Security Features (Week 5) (+1 more)

Best Practices

✅ DO

Include acceptance criteria for each requirement
Provide architecture diagrams
Document API contracts
Specify performance requirements
List risks and mitigations
Include implementation timeline
Add success metrics
Document security considerations
Version your specs
Get stakeholder review

❌ DON'T

Be vague about requirements
Skip non-functional requirements
Forget about security
Ignore alternatives
Skip testing strategy
Forget monitoring/observability
Leave questions unanswered

technical-specification

Technical Specification

Table of Contents

Overview

When to Use