authoring-developer-guide

Write developer-tool adoption and integration guides grounded in feature-specs and API references.

1|1|Updated May 24, 2026
One-click install
npx skills add https://github.com/bm629/agent-skills --skill authoring-developer-guide-bm629
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: authoring-developer-guide
Source: https://github.com/bm629/agent-skills/tree/main/skills/authoring-developer-guide
Command: npx skills add https://github.com/bm629/agent-skills --skill authoring-developer-guide-bm629

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Developer guides for SDKs, libraries, CLIs, frameworks, and API platforms often fail readers: no clear starting point, hello-world examples that never reach real value, fabricated endpoints, and samples that go stale when the tool ships a new version. This Skill provides the method and quality bar for authoring (or amending) a developer guide that takes a reader from install to a verified first success and on to a correct production integration. ## Core Features & Use Cases - Method-driven authoring: Organizes the guide around developer goals rather than endpoints, enforces concepts-before-recipes, correctly typed Diataxis modes (tutorial, how-to, explanation, reference), and a signposted start-here with a fast, verifiable first call. - Grounded, never fabricated content: Drives recipes and code samples off the handed-in feature-spec and api-reference, surfaces missing upstreams as explicit assumptions, and links into the API reference instead of duplicating it. - Versioned amend workflow: Edits an existing guide in place when the tool changes, sweeping every sample and recipe for stale references, bumping the guide's own version, and marking superseded content. - Use Case: Given a feature-spec and api-reference for a payments SDK, produce a guide with a runnable getting-started (env-var credentials, sandbox first call, expected output), goal-named integration recipes, an end-to-end tutorial, production best-practices (retries, idempotency, pagination, webhooks), and a troubleshooting path. ## Quick Start Use authoring-developer-guide to turn the attached feature-spec and api-reference into a developer guide for our SDK.

Frequently Asked Questions about authoring-developer-guide

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a developer guide for an SDK or API?

Organize the guide around developer goals rather than endpoints: a signposted start-here, a getting-started that reaches one verified real call, core concepts before recipes, goal-named how-to guides, an end-to-end tutorial, best-practices, and troubleshooting. Drive every code sample off the feature-spec and api-reference.

What should a getting-started section for a developer tool include?

A getting-started should cover prerequisites including where credentials come from, install commands, credential configuration via environment variables, one real successful call through test or sandbox mode, a verify step with literal expected output, and the two or three most common first-call failures.

How do I update developer documentation when the tool releases a new version?

Edit the guide in place rather than regenerating it: scope the delta, sweep every sample and recipe that referenced the changed or removed capability, re-check internal coherence, bump the guide's own version with a changelog entry, and mark superseded content with its replacement.

What is the difference between a developer guide and an API reference?

A developer guide is the adoption and integration narrative a developer reads to install, integrate, and operate the tool, while the API reference is the exhaustive per-endpoint catalog. The guide narrates scenarios and links into the reference; it never re-lists parameters, types, or errors.

When should I not use this developer guide authoring approach?

Do not use it for the exhaustive API reference catalog, non-technical end-user product help, or internal engineering documents like API specs, architecture docs, or data models. Reviewing a finished guide is also out of scope; that belongs to a separate reviewing skill.