Indexed PRD and Design Doc Strategy

James Phoenix
James Phoenix

A documentation-driven development pattern where a single index.md links all PRDs and design documents, creating navigable context for both humans and AI agents.

The Problem

Product requirements and design documents scatter across folders. Finding the right doc requires folder diving. AI agents lack a single entry point to understand system scope.

The Solution

Create a docs/index.md that serves as the single source of truth:

docs/
├── index.md           ← Central navigation hub
├── prd/
│   ├── PRD-001-core-feature.md
│   ├── PRD-002-secondary-feature.md
│   └── ...
└── design/
    ├── DD-001-data-model.md
    ├── DD-002-service-layer.md
    └── ...

Index Structure

The index.md contains:

1. PRD Table

PRD Title Status
PRD-001 Core Feature Phase 1
PRD-002 Authentication Phase 2

2. Design Doc Table

DD Title Implements
DD-001 Data Model PRD-001
DD-002 Auth Flow PRD-002

The “Implements” column creates explicit traceability between design and requirements.

3. Implementation Phases

Group PRDs by release phase:

Leanpub Book

Read The Meta-Engineer

A practical book on building autonomous AI systems with Claude Code, context engineering, verification loops, and production harnesses.

Continuously updated
Claude Code + agentic systems
View Book
  • Phase 1 (MVP): Core functionality
  • Phase 2: Integrations
  • Phase 3: Advanced features

4. Key Technical Decisions Table

Decision Choice Reference
Database SQLite DD-001
Framework Effect-TS DD-002

One-line rationale with pointer to the design doc that expands on it.

5. Dependency Graph (ASCII)

PRD-001 (Core) ──────► DD-001 (Data Model)
       │
PRD-002 (Auth) ──────► DD-002 (Auth Flow)

Shows how requirements flow into design decisions.

Naming Convention

  • PRDs: PRD-NNN-kebab-title.md (e.g., PRD-001-core-task-management.md)
  • Design Docs: DD-NNN-kebab-title.md (e.g., DD-001-data-model-storage.md)

Sequential numbering makes ordering clear. Kebab-case titles make files greppable.

Why This Works

  1. Single entry point: Point an AI agent at docs/index.md and it understands the entire system scope
  2. Traceability: Design docs reference PRDs they implement. No orphaned specs.
  3. Phase awareness: Anyone can see what’s MVP vs. future
  4. Decision log: Technical decisions are captured with references, not buried in Slack
  5. Greppable: git grep PRD-003 finds all references instantly

AI Agent Benefits

When you give Claude (or any LLM) access to index.md:

  • It sees all PRDs and DDs in one glance
  • It can navigate to specific docs via links
  • It understands implementation phases and priorities
  • It can trace requirements to implementations
  • It has context without reading every file

Template

# [Project] Documentation Index

Brief project description.

## Product Requirements Documents (PRDs)

| PRD | Title | Status |
|-----|-------|--------|
| [PRD-001](prd/PRD-001-xxx.md) | Title | Phase N |

## Design Documents (DDs)

| DD | Title | Implements |
|----|-------|------------|
| [DD-001](design/DD-001-xxx.md) | Title | PRD-001 |

## Implementation Phases

### Phase 1 (vX.X.X) - MVP
- Core functionality

### Phase 2 (vX.X.X) - Expansion
- Additional features

## Key Technical Decisions

| Decision | Choice | Reference |
|----------|--------|-----------|
| Database | X | DD-001 |

## Dependency Graph

[ASCII diagram showing PRD → DD relationships]

Real Example

See: tx Documentation Index


Related:

Explore it visually

Topics
Ai AgentsData EngineeringDeveloper ExperienceDocumentation

Newsletter

Become a better AI engineer

Weekly deep dives on production AI systems, context engineering, and the patterns that compound. No fluff, no tutorials. Just what works.

Join 306K+ developers. No spam. Unsubscribe anytime.


More Insights

Cover Image for Why I Threw Away My Video Harness When Opus 5.5 Arrived

Why I Threw Away My Video Harness When Opus 5.5 Arrived

I spent £700 on video analysis. A week later, Opus 5.5 outperformed my custom harness and changed how I think about constraints, consistency and model progress.

James Phoenix
James Phoenix
Cover Image for Build Features in the CLI Before the API

Build Features in the CLI Before the API

Make the next app as much of a CLI app as possible. Feature work happens in the terminal, in-process, against the real development database. The HTTP API is a thin adapter you add afterwards, and a lint rule fails CI if it ever gets a route the CLI does not have.

James Phoenix
James Phoenix