Skill: Technical Documentation Writer

Load this skill before any documentation task: writing API docs, setup guides, README files, internal process docs, runbooks, configuration references, or onboarding documentation.

Works in the same way as the Editorial Voice skill: load it as persistent context (Claude Project, Custom GPT, system prompt) and it shapes all documentation output within the session.

Particularly useful when you are documenting something you built and need to translate your "I know how this works" into documentation that someone else can follow.

"Show, then explain" reverses the default LLM pattern. Models naturally explain at length before showing the code. Developers want the opposite. They want to see the command, understand it at a glance, and read the explanation only if they need it. This single principle transforms the readability of AI-generated documentation.

Documentation type templates remove structural guesswork. The model does not have to decide what sections a README needs. The template defines it. This ensures completeness (nothing important is missing) and consistency (every README follows the same structure).

"Assume competence" prevents the most common frustration with AI documentation: explaining things the reader already knows. A developer does not need the AI to explain what npm is. They need to know which packages to install and what flags to use.

Complete, copy-pasteable examples are the quality bar. Partial examples that require the reader to fill in gaps are the number one complaint about technical documentation. The anti-pattern rule ("do not show partial examples") and the self-check ("is every code example copy-pasteable?") enforce this standard.

Add your tech stack. Append a section: "## Stack Context: This project uses [Next.js / Python / Go / etc]. All examples should use [specific framework conventions]. Import statements should be included. Use [your package manager]."

Adjust the assumed competence level. For internal team docs where the audience is very specific, you can raise the bar: "The reader is a senior developer familiar with [specific tools]." For public-facing docs, you might lower it slightly: "The reader may be new to [this framework] but is experienced with [general category]."

Add your formatting conventions. If your team has specific conventions (e.g. admonition syntax for your docs platform, specific heading structures), add them to the Formatting Rules section.

This skill optimises for developer documentation. It is not ideal for end-user documentation (help articles, FAQ pages) which requires a different tone and structure — more empathetic, less terse.

The quality of documentation is limited by the accuracy of the technical information the model has access to. For proprietary tools or very recent technologies, you may need to provide the technical details and let the skill handle the structuring and formatting.

Claude: Produces excellent technical documentation. Follows the "show, then explain" pattern reliably. Code examples are typically complete and well-formatted. The [VERIFY] flag instruction works well — Claude will mark uncertain details rather than fabricating.

GPT: Good with code-heavy documentation. May occasionally lapse into conversational tone ("Great, now let's..."). Reinforce: "No conversational language in documentation."

Gemini: Solid for structured documentation. Tables and parameter lists are well-formatted. May be more verbose in explanations than necessary. Add a word limit per explanation if conciseness is critical.