authoring-developer-guide — SKILL.md

Variant: standard · When to use: authoring (or amending) the developer-tool adoption + integration narrative — to a bar where a developer can install the tool, grasp its model, complete the common integration scenarios, self-serve the common errors, and operate it in production from the guide alone, with runnable code, every step matching what the tool actually does.

Overview

This skill is the how-to of writing a strong developer guide — the consumer-facing adoption and integration narrative for a developer-tool product (an SDK, library, CLI, framework, or API platform). It is the prose a developer reads to go from zero to a working integration and on to a correct production integration: reach a first successful call fast, find their way (a signposted start-here), understand the tool's mental model, follow code-centric recipes, build a small real thing end to end, apply production best-practices, and self-serve the common errors — with pointers out to the exhaustive reference. It spans the full Diataxis quadrant (tutorial / how-to / explanation / reference) for a technical reader. This skill carries the producer's judgment — the research method and the quality bar — not the section list. It assumes two collaborators: a developer-guide template tool that supplies the section structure, and a deep-research capability to ground the guide in established developer-experience (DX) docs practice, Diataxis, and the developer-docs quality rubric (Findability / Accuracy / Relevance / Clarity / Completeness / Readability). The producer is handed the upstream documents the plan determined inform this guide — never a blank page. The bar to clear: a developer can install, grasp the model, complete the common integration scenarios, and recover from the common errors from the guide alone, with runnable code, every step matching what the tool actually does.

This skill also amends an existing guide (the common real operation — see Step 6): a developer guide is the most change-driven of docs because its subject (the tool) moves.

When to activate

• Authoring the adoption + integration narrative for a developer-tool product (SDK, library, CLI, framework, or API platform).
• Writing the getting-started, core-concepts, integration recipes, end-to-end tutorial, best-practices, and troubleshooting a developer needs.
• Amending an existing developer guide when the tool changes (a new version, a deprecated/renamed/changed capability) or a recipe/concept needs correcting — see Step 6.
• Filling a developer-guide template with researched, runnable, accurate content driven off the handed-in feature-spec and api-reference.

Do NOT activate when: