Technical

Who Technical is for

For engineers who have to write the documentation and would rather be building. Also for teams whose SOPs live in one person’s head, where the problem is not knowing the process but writing it down in a form someone else can follow.

What Technical does

Paste code, a specification, or a plain-language description and choose a document type; Technical produces the structure that type requires. Output arrives as individually editable sections rather than one block of prose, which matters more than it sounds — when one section is wrong you fix that section instead of regenerating the whole document and losing the three parts that were fine. It writes for a stated audience, so a README for users reads differently from one for contributors.

• →API docs, SOP, user manual and README modes
• →Audience-aware writing
• →Individually editable sections
• →Markdown and DOCX export

How Technical works

1. 01

   Supply the source

   Code, a spec, or a description in plain language. Any of the three works.

2. 02

   Choose the document type

   API docs, SOP, user manual or README. The type determines the structure, not just the title.

3. 03

   Set the audience

   Who reads this. A user manual and a contributor guide describing the same software share almost nothing.

4. 04

   Edit section by section

   Sections are independently editable, so fixing one does not mean regenerating the document.

What Technical does not do

Technical documents what you show it. It does not read your repository, follow imports or understand runtime behaviour, so documentation generated from a fragment describes that fragment. Generated docs need technical review — plausible and wrong is the characteristic failure of generated documentation, and it is more dangerous than an obvious gap. It does not publish to a docs site or keep documentation in sync as code changes.

Common questions

Works well with