Docs Updater
Regenerate CHANGELOG and README-style docs from git history after shipping features or before tagging a release.
Overview
docs-updater is an agent skill most often used in Build (also Ship) that turns git diffs since the last tag into updated CHANGELOG and documentation entries.
Install
npx skills add https://github.com/giuseppe-trisciuoglio/developer-kit --skill docs-updaterWhat is this skill?
- Compares current branch to latest release tag and lists added or modified doc paths
- Detects semver from branch context for accurate version-scoped changelog entries
- Supports monorepos with multiple plugins and per-plugin SKILL.md updates
- Release-prep workflow to flush Unreleased sections before you cut a tag
- Continuous sync after feature commits with user-prompted doc refresh
Adoption & trust: 923 installs on skills.sh; 271 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped code and new SKILL files but your CHANGELOG and reference docs still describe the old release.
Who is it for?
Maintainers of plugin monorepos or agent skill collections who tag releases and need changelog accuracy without a separate doc writer.
Skip if: Teams that want auto-generated API reference from JavaDoc alone with no git-tag workflow, or products with no versioned release tags.
When should I use this skill?
After implementing features or when preparing a release and documentation must reflect commits since the last tag.
What do I get? / Deliverables
You get tag-scoped change summaries and markdown changelog sections ready to commit before or right after a release.
- CHANGELOG Unreleased or version sections
- Updated skill reference paths listed from diffs
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Documentation is owned in Build; this skill is the canonical shelf for keeping repo docs truthful as code changes. It diffs against release tags and rewrites changelog and reference docs—the core docs subphase deliverable loop.
Where it fits
After adding a DynamoDB patterns skill, regenerate Unreleased changelog bullets listing new SKILL.md paths.
Before cutting v2.5.0, reconcile all doc drift against v2.4.1 so the tag matches user-facing notes.
Post-release hotfixes: refresh changelog entries so support and downstream users see what changed.
How it compares
Use instead of hand-editing CHANGELOG from memory or copying commit messages one by one into release notes.
Common Questions / FAQ
Who is docs-updater for?
Solo and indie builders maintaining documentation-heavy repos—especially multi-plugin kits—who release on git tags and want agents to draft changelog updates from real diffs.
When should I use docs-updater?
Use it in Build after feature work to sync docs, in Ship while preparing a version bump, and before Launch comms when release notes must match what merged since the last tag.
Is docs-updater safe to install?
Review the Security Audits panel on this Prism page and inspect what files the skill reads or writes in your repo before letting an agent run it on production branches.
SKILL.md
READMESKILL.md - Docs Updater
# Universal Documentation Updater - Usage Examples This document provides practical examples of using the Universal Documentation Auto-Updater skill in various scenarios. ## Table of Contents 1. [Basic Workflow](#basic-workflow) 2. [Release Preparation](#release-preparation) 3. [Continuous Documentation Sync](#continuous-documentation-sync) 4. [Multi-Plugin Projects](#multi-plugin-projects) 5. [Troubleshooting](#troubleshooting) ## Basic Workflow ### Scenario: Adding a New Feature After implementing a new feature and committing your changes: ``` User: "Update docs for the new DynamoDB skill I just added" ``` **Expected Output:** ```bash Latest release tag: v2.4.1 Current branch: develop Version detected: 2.4.1 Comparing: v2.4.1 -> develop Commits since v2.4.1: 3 Changed files: A plugins/developer-kit-typescript/skills/dynamodb-toolbox-patterns/SKILL.md A plugins/developer-kit-typescript/skills/dynamodb-toolbox-patterns/references/schema.md M plugins/developer-kit-typescript/.claude-plugin/plugin.json ``` **Generated CHANGELOG Entry:** ```markdown ## [Unreleased] ### Added - **New DynamoDB-Toolbox v2 skill** (`developer-kit-typescript`): - `dynamodb-toolbox-patterns`: TypeScript patterns for DynamoDB-Toolbox v2 - Includes schema/table/entity modeling and query/scan access patterns ``` ## Release Preparation ### Scenario: Preparing for v2.5.0 Release Before creating a release tag, ensure all documentation is up to date: ``` User: "Prepare documentation for v2.5.0 release" ``` **Analysis Summary:** ```bash Latest release tag: v2.4.1 Commits since v2.4.1: 47 Commit breakdown: - Features: 15 - Bug fixes: 8 - Breaking changes: 3 - Documentation: 12 - Refactoring: 9 ``` **Proposed Documentation Updates:** ```markdown ## Proposed Documentation Updates ### Version Information - Previous release: v2.4.1 - Current branch: main - Commits analyzed: 47 ### Files to Update - [x] CHANGELOG.md - Add [2.5.0] section with date - [x] README.md - Update skills list, version badges - [ ] plugins/developer-kit-java/docs/ - No changes needed - [ ] plugins/developer-kit-aws/docs/ - Update SAM examples ### Summary of Changes **Added**: 5 new skills, 10 new features **Changed**: 3 component enhancements **Fixed**: 8 bug fixes **Breaking**: 3 breaking changes (migration notes required) ``` ## Continuous Documentation Sync ### Scenario: Regular Documentation Maintenance Keeping documentation synchronized after regular development iterations: ``` User: "Sync documentation with latest changes" ``` **Quick Analysis (Small Changes):** ```bash Latest release tag: v2.5.0 Commits since v2.5.0: 5 Changes: M plugins/developer-kit-core/skills/github-issue-workflow/SKILL.md M plugins/developer-kit-core/commands/devkit.brainstorm.md ``` **Generated Update:** ```markdown ## [Unreleased] ### Changed - **GitHub Issue Workflow skill**: Enhanced security handling for untrusted issue content - **Brainstorm command**: Added AskUserQuestion gates for user confirmation ``` ## Multi-Plugin Projects ### Scenario: Developer Kit Multi-Plugin Structure When working with a multi-plugin repository like the developer-kit: ``` User: "Update all docs across all plugins" ``` **Discovered Documentation Structure:** ```bash Documentation folders found: - plugins/developer-kit-java/docs/ - plugins/developer-kit-typescript/docs/ - plugins/developer-kit-aws/docs/ - plugins/developer-kit-python/docs/ - plugins/developer-kit-php/docs/ Documentation files found: - README.md - CHANGELOG.md - CONTRIBUTING.md - CLAUDE.md ``` **Per-Plugin Changes Detected:** ```markdown ## [Unreleased] ### Added **developer-kit-java:** - `spring-boot-actuator`: Production-ready monitoring patterns - `spring-boot-cache`: Caching configuration patterns **developer-kit-typescript:** - `dynamodb-toolbox-patterns`: DynamoDB-Toolbox v2 integration - `drizzle-orm-patterns`: Drizzle ORM comprehensive patterns **developer-kit-aws:** - `aws-sam-