DocFlow
Automated Product Documentation
From Git to Living Docs
Git history is the most honest record of what was built and why. DocFlow parses every commit, groups them into narratives, tracks architecture decisions, and maintains an always-current changelog — without anyone writing a word by hand.
What It Does
Six documentation layers. One source of truth.
Most documentation systems require someone to write the docs. DocFlow inverts this — it reads what was actually built and produces documentation as a byproduct of development.
Commit Narratives
Groups commits by product, sprint, or release. Extracts conventional commit categories (feat, fix, perf, docs), counts insertions/deletions, identifies top contributors, and builds a structured changelog with highlights — all from git log.
Architecture Decision Records
ADRs that live alongside the code. Detection methods include manual, git-pattern (commit keywords trigger a draft), and file-pattern (new config files prompt an ADR). Status lifecycle: proposed → accepted → deprecated → superseded. Numbered per product.
API Snapshots
Versioned OpenAPI spec snapshots with diff-from-previous. Tracks endpoint count changes over time. When an API breaks backwards compatibility, DocFlow has the diff. Commit SHA links each snapshot to the exact code state that generated it.
Test Coverage Snapshots
Pass/fail/skip counts and coverage percentage at every commit. Module-level coverage breakdown stored as JSONB for trend queries. Duration tracking shows whether the test suite is growing faster than the codebase warrants.
Feature Lifecycle
Tracks features from spec to deployment. Stages: spec → design → implement → test → deploy. Linked to Linear issue IDs, spec file paths, and related commits. Completion percentage and deploy timestamp make sprint reporting automatic.
Session Logs
A session-level record of every working session: duration, commit count, products touched, files changed, agents dispatched, decisions made, highlights. The raw material for weekly reports, retrospectives, and investor updates — already written.
How It Works
Git → Parse → Narrate → Store. No humans required.
Git log parsing
The git parser calls git log with a structured format, splits commits by product (detected from changed file paths), extracts conventional commit types, and computes stat summaries (insertions, deletions, file count) per commit. All git calls use execFileSync — no shell injection surface.
Grouping & categorisation
Commits are grouped by product, then by time period (daily, weekly, or 2-week sprint). Category counts (feat: 18, fix: 12, …) are computed per group. Top contributors, total line changes, and commit highlights are extracted for each narrative bucket.
Narrative generation
Phase 1 generates structured template narratives (title, summary, category breakdown, commit highlights) without an LLM dependency. Phase 2 will populate the ai_narrative field via the Anthropic API for prose-quality changelogs. The schema supports both — switching is a one-field update.
Persistence & export
Narratives are stored in PostgreSQL with full raw commit JSONB for reprocessing. Every narrative is addressable by ID. The export endpoint renders any saved narrative as a Markdown file — ready for Notion, Linear, or a GitHub release.
Key Numbers
Real metrics from the running system.
API
Four endpoints. Clean REST.
/api/docflow/changelogs List narratives with product, date, and group_type filters. Paginated.
/api/docflow/changelogs/:id Fetch a single narrative with full raw_commits JSONB.
/api/docflow/changelogs/generate Trigger generation for a product + date range. Optionally persist.
/api/docflow/changelogs/export/:id Export a saved narrative as a Markdown file download.
Your git history is already the documentation.
DocFlow just makes it readable.
627 commits in the last 30 days. Zero changelog entries written by hand. That's the baseline.