Indexed PRD and Design Doc Strategy

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

2. Design Doc Table

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

3. Implementation Phases

Group PRDs by release phase:

• Phase 1 (MVP): Core functionality
• Phase 2: Integrations
• Phase 3: Advanced features

4. Key Technical Decisions Table

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:

• Compound Engineering Philosophy
• System Design and Invariants – The meta spec that sits above this index, capturing all subsystems, object models, and invariants in one document