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, so a human always reviews before merge
Repositories that document themselves, with a human approval gate. Where coverage is partial, whether from capped file counts or 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, that cross-file details arrive secondhand, is handled by always giving the synthesis step the full structural file tree alongside the summaries.