Doc Maintenance

Scans your git history since the last review, finds commits that touch user-facing features, then checks if your README, SPEC, and PRODUCT docs reflect reality. It's looking for the usual drift: features shipped but still in the roadmap section, capabilities marked "not supported" that already landed, quickstart commands that rotted. Creates a branch with minimal fixes and opens a PR. The philosophy here is surgical patches only, no rewrites or cosmetic changes, which keeps doc maintenance from turning into a bikeshedding vortex. Run it after major merges or on a schedule. Ignores dev-facing docs and refactor commits by design.

skills.sh installs: 260
GitHub stars: 112.7K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add paperclipai/paperclip --skill doc-maintenance --agent claude-code

Installs into .claude/skills of the current project.

Files

Doc Maintenance

Keep the documentation honest with minimum churn. The goal is alignment between docs and behavior, not stylistic rewrites or cosmetic re-organization. Reviewers should be able to read a diff and see "this updates docs to match recent behavior changes".

When to use

A PR or recent set of merges changed user-visible behavior: CLI flags, API shapes, default values, configuration keys, endpoints, environment variables, supported versions.
A user-reported bug traced back to outdated documentation.
A release is being cut and the docs need a pass against the merged commits.
A new feature shipped but only the engineer's PR description describes how to use it.

When not to use

The change is internal-only (private helper rename, refactor) with no user-visible impact.
You want to "improve the docs" without a behavior anchor. That is a separate scoped project, not maintenance — make a plan first.