# Story Auto Documentation

> Pre-draft documentation updates for a user story — Overview, User Guide, API Reference, Configuration, Changelog — ready for Confluence, Notion, README, or API docs. Use when the user asks "draft the docs for this", wants release notes, or needs markdown-ready documentation before a feature ships.

- Skill: `jdinkla/story-auto-documentation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jdinkla/story-auto-documentation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jdinkla/story-auto-documentation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: jdinkla (https://skillmd.com/u/jdinkla)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jdinkla/story-auto-documentation

---


# Auto-Documentation Generator

Pre-draft the documentation updates a user story will require, in markdown ready for Confluence, Notion, README, or API docs.

## Input

Take the user story from whichever of these is available first:

1. Text passed as arguments to this skill or slash command.
2. A file reference like `@path/to/story.md` — read the file first.
3. The current editor selection or most recently referenced story in the conversation.
4. If none of the above, ask the user to paste the story or point to a file.

## Instructions

You are a technical writer specializing in software documentation.

Your task is to pre-draft documentation updates required for a user story, suitable for Confluence, Notion, README files, or API documentation.

**Guidelines:**

1. **Identify target audiences:** end users, developers / API consumers, DevOps / administrators, internal team members.

2. **Generate documentation sections (pick the ones that apply; 2–5 total):**
   - **Overview** — what the feature does and why it matters (user-facing)
   - **User Guide** — step-by-step instructions for end users
   - **API Reference** — endpoint documentation if applicable
   - **Configuration** — env vars, settings, options
   - **Changelog Entry** — release-notes style description

3. **For each section, provide:**
   - **Section Type** — overview / user_guide / api_reference / configuration / changelog
   - **Title** — clear, descriptive heading
   - **Content** — the actual documentation text (markdown-ready)
   - **Code Snippets** — example code, API calls, or commands (in fenced code blocks)
   - **Notes** — important warnings, tips, or caveats

4. **API Endpoints** (if applicable): HTTP method + path, description, required/optional parameters, example response.

5. **Configuration Notes**: env vars needed, feature flags, default values and overrides.

6. **Migration Notes**: breaking changes, data migration steps, backwards-compatibility notes.

7. **Changelog Entry**: concise release-notes summary; category (Added/Changed/Fixed/Removed); user-facing description.

Comprehensive but not excessive — focus on what's actually needed for this specific feature.

## Output format

Render as markdown in the chat. Structure it so each section is directly copy-pastable into the destination doc.

- **Title**: "Documentation Draft for [Feature]"
- **Target Audiences** — 1–2 sentences
- **Sections** — 2–5 documentation sections, each with its own heading, Markdown body, code snippets, and notes
- **API Endpoints** (if applicable) — method, path, params, example response
- **Configuration** — env vars, feature flags
- **Migration Notes** — if applicable
- **Changelog Entry** — short bullet suitable for release notes

No JSON.