Templates

Build from decisions, not assumptions.

Ready-to-use templates for turning product decisions into implementation-ready specifications.

Browse Templates See the Documentation System

Product

PRDProduct Requirements Document

FSDFeature Scope Document

BRDBusiness Rules Document

UFDUser Flow Document

Design

DSDUI/UX Design Specification

Engineering

DDDDatabase Design Document

ASDAPI Specification Document

TADTechnical Architecture Document

Implementation

DRDevelopment Roadmap

AIAI Instructions

02 / Template library

Choose a specification. Start writing.

Each template gives you the structure, questions, and boundaries needed to define one layer of the product.

Product

01PRD

Product Requirements Document

Core question: “What are we building and why?”
Removes: Product ambiguity
Use when: Defining a new product, major product initiative, or substantial product direction.
Input: Product idea, problem, opportunity, users, and goals.
Output: Clear product definition.
Connects to: FSD

View Template

prd-template.md

# Product Requirements Document

## 1. Product Overview

### Product Name

### Product Type

### Version

## 2. Problem Statement

## 3. Target Users

### Primary Users

### Future Users

## 4. Product Vision

## 5. Goals

### Primary Goals

### Secondary Goals

## 6. User Needs

## 7. Value Proposition

## 8. MVP Scope

### Included

### Out of Scope

## 9. Success Criteria

## 10. Assumptions

## 11. Constraints

## 12. Risks

Download .md

02FSD

Feature Scope Document

Core question: “What can the product do?”
Removes: Feature ambiguity
Use when: Defining the scope and behavior of a product feature or module.
Input: Product requirements and intended outcomes.
Output: Explicit feature scope and functional boundaries.
Connects to: BRD → UFD

View Template

fsd-template.md

# Feature Scope Document

## 1. Feature Overview

### Feature ID

### Feature Name

### Module

### Purpose

## 2. Description

## 3. Scope

### Included

### Excluded

## 4. Priority

## 5. Release

### MVP

### Future

## 6. Dependencies

## 7. Functional States

## 8. Conditions

## 9. Feature Acceptance

Download .md

03BRD

Business Rules Document

Core question: “What rules must the product follow?”
Removes: Business ambiguity
Use when: A feature depends on explicit conditions, constraints, decisions, or exceptions.
Input: Feature scope and product decisions.
Output: Explicit business rules and constraints.
Connects to: UFD → DSD → DDD → ASD

View Template

brd-template.md

# Business Rules Document

## 1. Rule Overview

### Rule ID

### Rule Name

### Applies To

### Trigger

## 2. Condition

## 3. Expected Behavior

## 4. Exceptions

## 5. Priority

## 6. Dependencies

## 7. Rule Types

### Conditions

### Constraints

### Decisions

### Exceptions

## 8. Specification Gaps

Download .md

04UFD

User Flow Document

Core question: “How does the user move through the product?”
Removes: Behavioral ambiguity
Use when: Defining the user's path through a feature, including decisions, alternate paths, and errors.
Input: Feature scope and business rules.
Output: Explicit user and system behavior.
Connects to: DSD

View Template

ufd-template.md

# User Flow Document

## 1. Flow Overview

### Flow ID

### Flow Name

### Goal

### Actor

## 2. Entry Point

## 3. Preconditions

## 4. User Actions

## 5. System Responses

## 6. Decision Points

## 7. Alternate Paths

## 8. Error States

## 9. Empty States

## 10. Exceptional States

## 11. End State

## 12. Dependencies

Download .md

Design

05DSD

UI/UX Design Specification

Core question: “How should the product look, behave, and feel?”
Removes: Interface ambiguity
Use when: Turning defined behavior into an explicit interface and experience specification.
Input: User flows, business rules, feature scope.
Output: Implementation-ready interface behavior and states.
Connects to: DDD → ASD → TAD

View Template

dsd-template.md

# UI/UX Design Specification

## 1. Design Identity

### Screen ID

### Screen Name

### Feature

### Platform

## 2. Purpose

## 3. Entry State

## 4. Content

## 5. Interaction

## 6. States

### Default

### Loading

### Empty

### Error

### Success

## 7. Responsive Behavior

## 8. Accessibility

## 9. Design Dependencies

Download .md

Engineering

06DDD

Database Design Document

Core question: “What data does the system store and how is it related?”
Removes: Data ambiguity
Use when: Defining the entities, fields, relationships, constraints, and access boundaries required by the product.
Input: Features, rules, flows, and interface requirements.
Output: Explicit data model.
Connects to: ASD → TAD

View Template

ddd-template.md

# Database Design Document

## 1. Database Overview

## 2. Entities

### Entity ID

### Entity Name

### Purpose

## 3. Fields

| Field | Type | Required | Constraints | Description |
| --- | --- | --- | --- | --- |
| | | | | |

## 4. Relationships

## 5. Constraints

## 6. Indexes

## 7. Derived Data

## 8. Access Rules

## 9. Data Retention

## 10. Storage

## 11. Data Flows

## 12. Future Extensions

Download .md

07ASD

API Specification Document

Core question: “How do different parts of the product communicate?”
Removes: Communication ambiguity
Use when: Defining the contracts between frontend, backend, services, or other system components.
Input: Feature behavior, business rules, data model, architecture.
Output: Explicit communication contract.
Connects to: TAD → DR

View Template

asd-template.md

# API Specification Document

## 1. API Standards

### Base Path

### Authentication

### Response Format

## 2. Endpoint

### Endpoint ID

### Purpose

### Method

### Path

### Authentication

## 3. Request

### Parameters

### Headers

### Body

## 4. Validation

## 5. Success Response

## 6. Error Responses

## 7. Side Effects

## 8. Business Rules

## 9. Example Request

## 10. Example Response

Download .md

08TAD

Technical Architecture Document

Core question: “How should the software system be structured?”
Removes: Architectural ambiguity
Use when: Defining how the major software components are structured, separated, and connected.
Input: Data model, API contracts, design requirements, technical constraints.
Output: Explicit system architecture.
Connects to: DR

View Template

tad-template.md

# Technical Architecture Document

## 1. Architecture Overview

## 2. Components

### Component ID

### Component Name

### Purpose

### Responsibility

## 3. Inputs

## 4. Data

## 5. Outputs

## 6. Boundaries

## 7. Dependencies

## 8. Communication

## 9. Security Boundaries

## 10. Error Handling

## 11. Performance Considerations

## 12. Technology Decisions

## 13. Architecture Constraints

<!--
Do not force a particular architecture (microservices, monolith, serverless,
a specific cloud provider, etc.) into this document. Architecture decisions
belong to the actual product being specified.
-->

Download .md

Implementation

09DR

Development Roadmap

Core question: “In what order should the product be implemented?”
Removes: Implementation-order ambiguity
Use when: The specifications are sufficiently defined and implementation needs to be broken into an explicit sequence.
Input: Completed specifications and architecture decisions.
Output: Ordered implementation tasks.
Connects to: AI Instructions

View Template

dr-template.md

# Development Roadmap

## 1. Implementation Overview

## 2. Phases

### Phase

### Goal

### Dependencies

## 3. Tasks

### Task ID

### Task Name

### Description

### References

### Prerequisites

### Dependencies

### Scope

### Acceptance Criteria

### Verification

## 4. Implementation Order

## 5. Definition of Done

## 6. Verification Checklist

<!--
This is an implementation sequence derived from the specifications above it,
not project-management software. Keep tasks traceable to the documents that
define them.
-->

Download .md

10AI

AI Instructions

Core question: “How should the AI agent behave while implementing it?”
Removes: Agent-behavior ambiguity
Use when: A coding agent will implement the product from the documentation.
Input: The complete relevant documentation and development roadmap.
Output: Explicit operating rules for the AI implementation agent.
Connects to: Implementation

View Template

ai-template.md

# AI Instructions

## 1. Purpose

## 2. Operating Principles

> AI implements decisions. Humans own important decisions.

## 3. Documentation Reading Order

## 4. Traceability Requirements

## 5. Implementation Rules

## 6. Decision Boundaries

### AI May Decide

### Human Must Decide

## 7. Specification Gaps

If documentation is insufficient or contradictory:

### Detect

### Report

### Pause

### Request Decision

### Resume

Resume only after the decision is documented.

## 8. Conflict Handling

## 9. Verification Requirements

## 10. Reporting Requirements

## 11. Definition of Done

## 12. Final Workflow

READ
↓
TRACE
↓
CHECK
↓
IMPLEMENT
↓
VERIFY
↓
REPORT

Download .md

03 / Start building

Don't start with the code. Start with the specification.

Define the decisions first. Connect them across the system. Then give the implementation work to humans or AI with the ambiguity already removed.

Idea

Document

Trace

Plan

Implement

Verify

Review

↺ Review feeds back into documentation.

Download the PRD Browse Documentation