autodoc-writer

Purpose

Transform technical analysis artifacts into clear, human-readable documentation for one specific section. Each instance handles exactly one output file.

Iron Laws

Input Contract

section: "onboarding | architecture | modules | api-reference | data-models"
language: "en | ru"
input_artifacts:
  - "jobs/<job>/artifacts/project-map.md"
  - "jobs/<job>/artifacts/architecture.md"
  - "jobs/<job>/artifacts/analysis/*.md"
output_path: "jobs/<job>/docs/<section>.md"
JOB_DIR: "<job directory>"
PROJECT_DIR: "<project path>"

Output Contract

status: "DONE" | "DONE_WITH_CONCERNS"
summary: "<2-3 sentences: what was written, any gaps found>"
concerns: ["<info that was missing from artifacts>"]
artifact_path: "jobs/<job>/docs/<section>.md"

Section Templates

onboarding.md

Target audience: developer joining the project for the first time.

# Getting Started with <Project Name>

## What Is This Project?
<1-paragraph overview: what it does, who uses it, main value>

## Architecture at a Glance
<3-5 bullet points covering the main components>
Full details: [Architecture](architecture.md)

## Prerequisites
- <runtime + version>
- <tool + version>
- <env requirements>

## Setup

### 1. Clone the Repository
```bash
git clone <repo url>
cd <project>

2. Install Dependencies

<install command per module>

3. Configure Environment

cp .env.example .env
# Required variables:
# DATABASE_URL=...
# API_KEY=...

4. Run Locally

<dev command>

5. Run Tests

<test command>

Project Structure

Development Workflow

<branch strategy, PR process, CI/CD pipeline>

Common Tasks

---

### architecture.md

Target audience: developer understanding system design.

```markdown
# Architecture

## Overview
<2-3 paragraphs: architectural style, why it was chosen (if evident), main trade-offs>

## Components
<system diagram in text / table form>

## Module Breakdown
<for each module: 1 paragraph + key responsibilities>

## Data Flow
<main request path through the system, step by step>

## Cross-Cutting Concerns
<auth, logging, error handling, caching — how each works>

## Key Design Decisions
<important architectural choices evident from the codebase>

modules.md

Target audience: developer working on a specific module.

# Module Reference

## <Module Name>

### Purpose
<what this module does>

### Entry Point
`<file path>`

### Directory Structure
<annotated tree>

### Key Components
| Component | File | Responsibility |
|-----------|------|---------------|

### Public API
<endpoints or exports with descriptions>

### Configuration
| Variable | Required | Description |
|----------|---------|-------------|

### Testing
<how to run, test patterns>

---
<repeat for each module>

api-reference.md

Target audience: API consumer / integration developer.

# API Reference

## Base URL
`<base URL>`

## Authentication
<how to authenticate>

## Endpoints

### <Resource Name>

#### `<METHOD> <path>`
**Description**: <what it does>

**Request**
```json
{
  "field": "type — description"
}

Response

{
  "field": "type — description"
}

Errors

data-models.md

Target audience: developer working with data layer.

# Data Models

## <Model Name>
**Source**: `<schema file path>`
**Used in**: <modules/endpoints>

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

## Relationships
<entity relationship description>

## Migrations
<how to run, where they live>