Documentation rots the moment it is written. Could a pipeline read an entire repository, produce accurate README and ARCHITECTURE documents, open a pull request with them — and then keep them current automatically as the code changes?
- Fetches the repo tree via the GitHub API and filters to meaningful source files
- Uses a map-reduce LLM design: a fast, cheap model summarises each file individually; a stronger model synthesises repo-wide documentation from the summaries — scaling to large repos without giant prompts
- Runs as a full scan on demand, or incrementally from push and pull-request webhooks, documenting only what changed
- Creates a fresh branch, commits the generated docs, and opens a pull request — a human always reviews before merge
Repositories that document themselves, with a human approval gate. Where coverage is partial — capped file counts, failed fetches — the pipeline says so explicitly in the output rather than papering over gaps.
- n8n · GitHub REST API
- Anthropic API — tiered model usage
- Webhook triggers · PR automation
Built for the real GitHub
The naive version dies on contact with production: bulk file fetches trip abuse rate limits, transient 502s kill runs, and a silently dropped file corrupts the docs without anyone noticing. The pipeline serialises fetches with pacing, retries every call, continues past individual failures, and — critically — surfaces every failed fetch by name in the generated output, so a gap reads as a gap rather than a fact.
Why map-reduce beats one big prompt
Stuffing a whole repo into a single context window is expensive, hits limits on real codebases, and buries the signal. Per-file summarisation with a cheap model costs a fraction as much, parallelises cleanly, and gives the synthesis model exactly the distilled material it needs. The trade-off — cross-file details arrive secondhand — is handled by always giving the synthesis step the full structural file tree alongside the summaries.