Producing technical documentation that survives
Generate README, architecture and runbook documentation from the code itself, so docs can be regenerated instead of rotting.
BeginnerCOMMUNITY ANALYSISMarkdownMermaid
Prompt
Write technical documentation for this service: overview, architecture (with a Mermaid diagram), configuration reference from actual environment variables, local development setup, deployment, and a runbook for the three most likely failure modes. Cite file paths for every factual claim.
Problem
Documentation is written once at project start and is wrong within a quarter.
Scenario
A service about to be handed to another team.
Architecture
- Docs in-repo
- Regenerated on major changes, reviewed like code
Why Bob?
Docs derived from code can be regenerated cheaply, which changes the economics of keeping them current.
Prompt
Run from the repository root with the prompt above.
Bob Workflow
- Extract configuration from code, not from memory
- Draft diagrams as Mermaid
- Cite paths so reviewers can verify
Generated Result
A README, an architecture page and a runbook draft.
Validation
- Follow the setup steps on a clean machine
- Check every cited path exists
Security
Strip internal hostnames and credentials before publishing anything externally.
Lessons Learned
- Citations turn review from proofreading into verification
- Runbooks still need a human who has seen the incident
Resources
- Diátaxis documentation framework