Engineering Documentation Tools
Documentation & Review holds three generators for the writing engineers do around code: a technical design document before building, an incident postmortem after something breaks, and a commit message for each change. Tech leads, on-call engineers and anyone facing a blank template use them to get the structure right so the effort goes into the content.
3 free tools · no sign-up · no ads
All Documentation & Review (3)
Which tool do I need?
Write up a technical design for review
Fill in the project name, overview and problem statement, add whatever else you know, and download the generated design doc as Markdown.
Write the postmortem after an outage
Paste the timeline, record detection and resolution times, and add owned action items. Blank fields show as Not recorded rather than guesses.
Write a commit message that follows Conventional Commits
Choose the change type, describe the change and list the files. The tool builds the header, wraps the body and warns when the header is too long.
Turn postmortem action items into a follow-up design
Use the incident review to agree on the prevention work, then write the larger fixes up as a design doc for review.
About Documentation & Review
Each tool is a form that turns your answers into a standard structure. The Design Document Generator covers the problem statement, constraints, success criteria, architecture, options considered, implementation plan and risks, and fills blank sections with prompts that tell reviewers what is missing. The Incident Review Tool builds a blameless postmortem with a parsed timeline, time to detect, mitigate and resolve, and action items with owners and due dates. The Code Commit Message Tool writes a Conventional Commits 1.0.0 header with a scope taken from the first file, wraps the body at 72 columns and adds a BREAKING CHANGE footer when needed. In practice the three connect: a design doc's plan turns into commits, and a postmortem's action items often become the next design doc.
None of these tools writes the content for you. They organise what you enter and leave visible gaps where you entered nothing, which is deliberate, because an invented number in a postmortem or a made-up scope in a commit is worse than a blank. Nothing is saved or uploaded, so download the Markdown or copy the message before closing the tab, and keep editing in your wiki or repository, where the document will be reviewed.
Guides
- How to Write a Technical Design Doc Reviewers Actually ReadThe sections that matter, the ones people skip, and how to write alternatives, risks and rollout plans that settle arguments before the code is written.
- Blameless Incident Postmortems: A Template and How to Run OneWhat goes in a postmortem, how to build a timeline people trust, the difference between time to mitigate and time to resolve, and action items that actually get done.
- Conventional Commits and the 50/72 Rule, ExplainedThe commit header format release tools parse, how breaking changes are marked, why bodies wrap at 72 columns, and the git detail that silently deletes Markdown headings.
- The 5 Whys: Finding Root Causes Without Blaming PeopleHow Toyota's 5 Whys works, how to back each answer with evidence, when to stop, when to switch to a fishbone diagram, and a worked warehouse example.
Frequently asked questions
Why use a template for engineering documents?
A template makes sure the questions reviewers always ask are answered up front: what problem this solves, what was considered, how it will be tested, and who owns each follow-up. It also makes documents from different authors easy to compare and search later.
Do the documentation generators write content with AI?
No. They arrange and format what you type, splitting lists, phases, timeline entries and risks into the right sections. Anything you leave blank appears as a prompt or as Not recorded, so the gaps stay visible.
Where should design docs and postmortems live after I generate them?
Somewhere they will be reviewed and found again, usually a wiki, a docs folder in the repository, or your team's document tool. Paste the Markdown there and continue editing, since comments and later revisions belong with the document rather than in the generator.
How do design docs, postmortems and commit messages relate?
They record the same work at different scales. A design doc explains why a change is being made before it starts, commit messages explain each step as it lands, and a postmortem explains what went wrong afterwards. Linking them, for example a commit footer that references the design or incident, makes the history traceable.