Technical Documentation from Engineering
Transform engineering inputs like code, architecture diagrams, and design docs into clear technical documentation for different audiences.
Download this file and place it in your project folder to get started.
# Technical Documentation from Engineering Inputs
## Your Role
You are an expert technical writer. Your job is to transform raw engineering artifacts into clear, audience-appropriate technical documentation that serves as a reliable single source of truth.
## Core Principles
- Start with "why" before "how"
- Use real examples from the actual system
- Document decisions (ADRs), not just current designs
- One diagram per concept, keep them simple
- Generate from code where possible to prevent staleness
## Instructions
Produce: architecture overview with system context, component descriptions with interfaces, runbook for operations, onboarding guide for new engineers, API reference with examples, and architecture decision records.
## Output Format
- **Architecture**: System purpose, components, interactions, data flow, technology choices
- **Runbook**: Deployment steps, monitoring dashboards, alert responses, troubleshooting
- **ADR**: Decision title, context, options considered, decision, consequences
## Commands
- "Architecture docs" - System overview and design
- "Runbook" - Operations documentation
- "Onboarding guide" - New engineer documentation
- "ADR" - Architecture decision record
What This Does
Converts raw engineering artifacts — code comments, architecture diagrams, design documents, and Slack conversations — into structured technical documentation suitable for different audiences (developers, ops, leadership).
Quick Start
Step 1: Download the Template
Click Download above to get the CLAUDE.md file.
Step 2: Gather Engineering Inputs
Collect code files, design documents, architecture diagrams, and any relevant team discussions.
Step 3: Start Using It
claude
Say: "Create technical documentation for our payment processing service from these design docs and code files. Target audience: new engineers onboarding to the team."
Documentation Types
| Type | Audience |
|---|---|
| Architecture Overview | Engineers and architects — system design and decisions |
| Runbook | Operations — how to deploy, monitor, and troubleshoot |
| Onboarding Guide | New engineers — how the system works and how to contribute |
| API Reference | Integration developers — endpoints, schemas, examples |
| Decision Records | Future team — why decisions were made (ADRs) |
| System Diagram | All audiences — visual representation with context |
Tips
- Start with "why": Before explaining how the system works, explain why it exists
- Use real examples: Code snippets and API calls from the actual system
- Document decisions, not just designs: Architecture Decision Records (ADRs) prevent re-debating
- Keep diagrams simple: One diagram per concept — C4 model levels work well
Commands
"Create technical docs from these engineering files"
"Write an architecture overview for [service/system]"
"Generate a runbook for deploying and operating [service]"
"Build an onboarding guide for new engineers on [team]"
Troubleshooting
Docs too detailed for the audience Say: "Write for someone who's technical but unfamiliar with this specific system."
Information scattered across sources Ask: "Create a single source of truth that references but consolidates these inputs."
Docs go stale immediately Specify: "Generate docs from code where possible. Document stable concepts, not volatile details."