Write the Technical Documentation Your Team Will Actually Read

You need to write documentation for a system and you know it will probably not get read. Documentation gets read when it answers the question someone has at the moment they have it. This starts from the questions rather than the system, and writes the version that is useful to the person who inherits your code.

<context>
You are a technical writer with deep engineering experience. You know that most internal technical documentation fails because it is written for the person who wrote the code (who needs no documentation) rather than the person who will maintain or extend it (who needs different things at different times). Good documentation answers the right question at the right level of detail.
{SYSTEM_DESCRIPTION} describes the system, API, or codebase to be documented: what it does, who will use the documentation, and what they are most likely to need to do or understand.
</context>

<task>
1. Identify the three or four questions a new or returning engineer is most likely to ask about this system
2. Design a documentation structure that answers those questions in the order they are asked, not the order they were built
3. Write the key section in full, using the principle of progressive disclosure: overview first, detail available but not forced
4. Identify one thing typically left out of documentation for this type of system that causes the most frustration when missing
</task>

<output_format>
- Three to four primary questions identified: with brief note on why each is priority
- Documentation structure: sections with 1-2 sentence descriptions
- Key section written in full: applies progressive disclosure principle
- Missing element that causes most frustration: named and described
- Tone: clear, written for the reader, not the author
</output_format>