Decisions

  • Pending: Auto-generate on merge or on-demand?
  • Pending: Doc format — markdown in vault or standalone site?
  • Pending: Which docs to generate — API, architecture, user guide, or all?

User Tasks


Summary

Automatically generate and maintain documentation from code, vault structure, and FR history — keeping docs in sync with the actual system.

Problem / Motivation

  • As src/ grows, there’s no automatic documentation of modules, APIs, or architecture.
  • Vault structure and conventions are documented in CLAUDE.md but become stale as the system evolves.
  • The orchestrator (FR-056) can ship code autonomously, but nobody updates the docs — they drift immediately.
  • External project support (FR-065) means onboarding docs are needed for each project.
  • Manual documentation is the first thing to be skipped under time pressure.

Proposed Solution

A /docs skill and a post-merge pipeline step that generates documentation from: (1) Python docstrings/type hints → API docs, (2) vault structure → system docs, (3) FR history → changelog/release notes. Output goes to vault/00_system/docs/generated/.


Open Questions

1. Documentation Scope

Question: What types of documentation should be generated?

OptionDescription
A) API + Architecture + ChangelogCode docs + system overview + what changed
B) API onlyJust code documentation
C) Everything including user guideFull documentation suite

Recommendation: Option A — covers the three most likely to drift.

Decision:

2. Generation Tooling

Question: What tools should generate the docs?

OptionDescription
A) LLM-generated from sourceClaude reads code/vault and writes markdown docs
B) Traditional toolsSphinx/mkdocs for Python, custom scripts for vault
C) HybridTraditional tools for API, LLM for architecture/changelog

Recommendation: Option C — use proven tools where they exist (Sphinx/mkdocs for API docs), LLM for narrative docs that need judgment.

Decision:

3. Trigger

Question: When should docs be regenerated?

OptionDescription
A) Post-merge + on-demandAuto-update after PR merge, /docs for manual
B) On-demand onlyUser/orchestrator runs /docs when needed
C) ContinuousWatch for changes, regenerate affected docs

Recommendation: Option A — auto after merge catches drift, on-demand for ad-hoc.

Decision:


Phase Overview

PhaseDescriptionStatus
Phase 1/docs skill — generate API docs from Python code
Phase 2Architecture doc generation from vault structure
Phase 3Auto-trigger on merge + changelog from FR history

Phase 1: API Documentation —

Goal: Generate Python API documentation from docstrings and type hints.

File / FeatureDetailsOwnerStatus
.claude/skills/docs/SKILL.md/docs skill definitionopus
vault/00_system/docs/generated/api/Output directory for API docsopus
Tool selectionmkdocs + mkdocstrings or Sphinx + autodocopus
pyproject.toml updateAdd docs dependenciesopus
Module indexAuto-generated index of all src/opus/ modulesopus

Phase 2: Architecture Documentation —

Goal: Generate system architecture docs from vault structure and CLAUDE.md.

File / FeatureDetailsOwnerStatus
vault/00_system/docs/generated/architecture.mdAuto-generated architecture overviewopus
Vault structure scannerRead directory tree, generate structure docopus
Component diagramMermaid diagram of system componentsopus
Skill/hook/agent inventoryAuto-generated list of all configured skills, hooks, agentsopus

Phase 3: Auto-Trigger & Changelog —

Goal: Auto-regenerate docs after merges and generate changelogs from FR history.

File / FeatureDetailsOwnerStatus
Post-merge hookTrigger doc regeneration after PR mergeopus
Changelog generatorParse done/ FRs → generate changelog grouped by date/phaseopus
vault/00_system/docs/generated/changelog.mdAuto-generated changelogopus
Orchestrator integrationFR-056 pipeline includes doc-update step after mergeopus

Test

Manual tests

TestExpectedActualLast
Merge PR, verify auto-triggerDocs regenerated automaticallypending-
Check changelog after completing FRFR appears in changelogpending-

AI-verified tests

ScenarioExpected behaviorVerification method

E2E tests

ScenarioAssertion

Integration tests

ComponentCoverage

Unit tests

ComponentTestsCoverage

History

DateEventDetails
2026-03-12CreatedIdentified as gap for autonomous coding agency

References

  • FR-056 (Autonomous Coding Orchestrator) — doc-update as pipeline step
  • FR-015 (Python Project Scaffold) — pyproject.toml setup for doc tools
  • FR-042 (Session Changelog) — per-session logs, this FR covers release-level changelog
  • FR-065 (Multi-Repo) — external projects need onboarding docs
  • FR-048 (Workflow Documentation) — manual docs, this FR auto-generates