## Codebase Discovery Checklist

### Structure Analysis
- [ ] Identify root directories and their purposes
- [ ] Map major components/modules
- [ ] Find configuration files
- [ ] Locate entry points

### Pattern Recognition
- [ ] Architectural pattern (layered, microservices, etc.)
- [ ] Design patterns in use
- [ ] Code organization conventions
- [ ] Naming conventions

### Dependency Mapping
- [ ] External dependencies
- [ ] Internal module dependencies
- [ ] Service integrations
- [ ] Database connections

### Key Files to Read
- README.md
- package.json / requirements.txt / go.mod
- Configuration files
- Main entry points
- Core business logic

## Documentation Structure Template

### 1. Executive Summary (1 page)
- System purpose
- Key capabilities
- Technology stack overview
- Quick start guide

### 2. Architecture Overview (5-10 pages)
- System context diagram
- Component overview
- Data flow
- Integration points
- Key design decisions

### 3. Components Deep Dive (per component)
- Purpose and responsibilities
- API/interface documentation
- Configuration options
- Dependencies
- Code examples

### 4. Data Models (5-10 pages)
- Entity relationship diagrams
- Schema documentation
- Data flow documentation
- Validation rules

### 5. Integration Guide (5-10 pages)
- API documentation
- Event documentation
- External service integrations
- Authentication/authorization

### 6. Deployment (5-10 pages)
- Infrastructure requirements
- Deployment procedures
- Configuration management
- Monitoring and logging

### 7. Operations (5-10 pages)
- Runbooks
- Troubleshooting guides
- Performance tuning
- Backup and recovery

### 8. Appendices
- Glossary
- References
- Change log

# [Component Name]

## Overview

[2-3 paragraph description of what this component does and why it exists]

## Architecture

### Position in System

[Where this component fits in the overall architecture]

### Key Design Decisions

| Decision | Rationale | Trade-offs |
|----------|-----------|------------|
| [Decision 1] | [Why this was chosen] | [What was traded off] |
| [Decision 2] | [Why this was chosen] | [What was traded off] |

## Implementation Details

### Core Classes/Functions

#### `ClassName` / `functionName`

**Purpose**: [What it does]

**Location**: `src/path/to/file.ts:line_number`

**Signature**:
```typescript
function functionName(param1: Type1, param2: Type2): ReturnType

// Example usage from codebase
const result = functionName(value1, value2);

Input → Validation → Processing → Output
  │         │            │          │
  │         ▼            ▼          ▼
  │    Reject if    Business    Store/
  │    invalid      Logic       Return

# Example configuration
setting_name:
  option_a: value
  option_b: value

npm test -- --grep "ComponentName"

## Documentation Types

### 1. Architecture Documentation

```markdown
# System Architecture

## Overview

[High-level description]

## System Context

                ┌─────────────────┐
                │   Web Browser   │
                └────────┬────────┘
                         │
                         ▼

## Component Architecture

### Component Diagram
[Detailed internal architecture]

### Component Descriptions

| Component | Responsibility | Technology |
|-----------|---------------|------------|
| API Gateway | Request routing, auth | Node.js |
| User Service | User management | Python |
| Order Service | Order processing | Go |

## Data Architecture

### Data Flow Diagram
[How data moves through system]

### Data Stores
| Store | Type | Purpose |
|-------|------|---------|
| PostgreSQL | Relational | Transactional data |
| Redis | Cache | Session, caching |
| S3 | Object | File storage |

## Security Architecture

### Authentication
[How users authenticate]

### Authorization
[How permissions work]

### Data Protection
[Encryption, etc.]

# API Reference

## Authentication

All API requests require a Bearer token:

```bash
curl -H "Authorization: Bearer <token>" https://api.example.com/v1/resource

{
  "data": [
    {
      "id": "usr_123",
      "email": "user@example.com",
      "name": "John Doe"
    }
  ],
  "meta": {
    "page": 1,
    "total": 100
  }
}

curl https://api.example.com/v1/users?page=1&limit=20 \
  -H "Authorization: Bearer $TOKEN"

### 3. Runbook Documentation

```markdown
# Runbook: [Procedure Name]

## Purpose
[What this runbook accomplishes]

## Prerequisites
- [ ] Access to [system/tool]
- [ ] Permissions for [action]
- [ ] [Other prerequisites]

## Procedure

### Step 1: [Action]

```bash
# Command to execute
command --with --flags

Expected output here

## Output Characteristics

- **Length**: Comprehensive documents (10-100+ pages)
- **Depth**: From bird's-eye view to implementation specifics
- **Style**: Technical but accessible, with progressive complexity
- **Format**: Structured with chapters, sections, and cross-references
- **Visuals**: Architectural diagrams, sequence diagrams, and flowcharts

## Best Practices

### Content

1. **Always explain the "why"** behind design decisions
2. **Use concrete examples** from the actual codebase
3. **Create mental models** that help readers understand the system
4. **Document both current state and evolutionary history**
5. **Include troubleshooting guides** and common pitfalls
6. **Provide reading paths** for different audiences

### Format

1. Clear heading hierarchy (H1 → H2 → H3)
2. Code blocks with syntax highlighting
3. Tables for structured data
4. Bullet points for lists
5. Blockquotes for important notes
6. Links to relevant code files (using `file_path:line_number` format)

### Maintenance

1. Keep documentation near the code
2. Update docs with code changes
3. Review documentation quarterly
4. Mark outdated sections clearly
5. Include last-updated timestamps

## Output Deliverables

When creating documentation, I will provide:

1. **Executive summary** - One-page overview for stakeholders
2. **Architecture overview** - System boundaries and key components
3. **Design decisions document** - Rationale behind choices
4. **Component documentation** - Deep dive into each module
5. **Data model documentation** - Schema and data flow
6. **Integration guide** - APIs and external services
7. **Deployment guide** - Infrastructure and operations
8. **Troubleshooting guide** - Common issues and solutions
9. **Glossary** - Terminology definitions

## When to Use This Skill

- Creating documentation for a new system
- Documenting existing undocumented code
- Writing architecture decision records
- Creating onboarding documentation
- Preparing for audits or compliance
- Building knowledge bases for teams
- Creating technical guides and manuals

Remember: Your goal is to create documentation that serves as the definitive technical reference for the system, suitable for onboarding new team members, architectural reviews, and long-term maintenance.