doc-maintenance
installsforks
How to install doc-maintenance?
getpaperclipai/paperclip/doc-maintenance
$npx -y skills add getpaperclipai/paperclip --skill doc-maintenanceKeep project docs aligned with recent code and feature changes — detect drift, update affected pages, and add release-relevant notes without rewriting unchanged sections.
SKILL.md
| 1 | # Doc Maintenance |
| 2 | |
| 3 | 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". |
| 4 | |
| 5 | ## When to use |
| 6 | |
| 7 | - A PR or recent set of merges changed user-visible behavior: CLI flags, API shapes, default values, configuration keys, endpoints, environment variables, supported versions. |
| 8 | - A user-reported bug traced back to outdated documentation. |
| 9 | - A release is being cut and the docs need a pass against the merged commits. |
| 10 | - A new feature shipped but only the engineer's PR description describes how to use it. |
| 11 | |
| 12 | ## When not to use |
| 13 | |
| 14 | - The change is internal-only (private helper rename, refactor) with no user-visible impact. |
| 15 | - You want to "improve the docs" without a behavior anchor. That is a separate scoped project, not maintenance — make a plan first. |
| 16 | |
| 17 | ## The pass |
| 18 | |
| 19 | 1. **Establish the baseline.** Get the commit range you are documenting against (since last release tag, since last merged-doc commit, or since a specific PR). |
| 20 | 2. **Enumerate user-visible changes.** Read commits and PR descriptions. List, for each change, what a user can now do differently. |
| 21 | 3. **Map changes to docs.** For each change, find every page that mentions the affected concept. Common targets: README, CLI reference, API reference, configuration reference, migration guide, FAQ, examples. |
| 22 | 4. **Update precisely.** Edit only the lines that need to change. Do not rewrap paragraphs you did not modify — it pollutes the diff. |
| 23 | 5. **Add new entries where needed.** New CLI flag → CLI reference entry. New env var → configuration reference entry. New endpoint → API reference entry. Don't only add it to the changelog. |
| 24 | 6. **Update examples and snippets.** Code blocks in docs are wrong faster than prose. Re-run any example that touches new behavior. |
| 25 | 7. **Write the release note.** One sentence per user-visible change. Group by Added / Changed / Fixed / Deprecated / Removed. Link to the relevant PRs and docs section. |
| 26 | 8. **Cross-check.** Search the docs for the old behavior wording and remove or update stragglers. |
| 27 | |
| 28 | ## Style baseline |
| 29 | |
| 30 | - Voice: second person ("you can pass `--json` to ..."). Avoid "we" except in narrative pages. |
| 31 | - Tense: present, not future. The behavior exists once shipped. |
| 32 | - Headings: imperative ("Configure the cache") or noun-phrase ("Cache configuration"), match the surrounding page. |
| 33 | - Code blocks: include the language tag so syntax highlighting works. |
| 34 | - Cross-links: link the first mention of a concept on each page; do not link every occurrence. |
| 35 | - Avoid promising future behavior. If something is unreleased, mark it `experimental` or omit it. |
| 36 | |
| 37 | ## Drift detection |
| 38 | |
| 39 | A doc page is drifting if any of these are true: |
| 40 | |
| 41 | - It documents a flag, key, or endpoint that no longer exists. |
| 42 | - An example does not run as written. |
| 43 | - A default value in the docs does not match the code. |
| 44 | - A supported-versions list excludes a version the project actually supports, or includes one it dropped. |
| 45 | - A "Coming soon" section references a feature that shipped or was cancelled. |
| 46 | |
| 47 | When you find drift, fix it in the same pass and note it in the release note's `Fixed` group. |
| 48 | |
| 49 | ## Release-note rules |
| 50 | |
| 51 | - One sentence per item. If two sentences are needed, the item is likely two items. |
| 52 | - User impact first, internal cause second. `Faster cold start (avoid full bundle download on first run)` beats `Refactor bootstrap loader`. |
| 53 | - Link the PR for engineering readers and the docs page for users. |
| 54 | - Mark breaking changes explicitly: `**Breaking:**` prefix. Include migration steps inline or via link. |
| 55 | |
| 56 | ## Anti-patterns |
| 57 | |
| 58 | - Massive doc PRs that bundle stylistic rewrites with real updates. Reviewers cannot tell which lines reflect actual behavior changes. |
| 59 | - "Updated docs" commit messages with no detail. Make the commit say what changed and why. |
| 60 | - Adding to the changelog without updating the reference docs the changelog points to. |
| 61 | - Marking a feature as available before its code lands. Documentation must follow behavior, not promise it. |
People who liked this also viewed
6 picksType
- grill-with-docsA relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.SkillsJul 2026
- lark-minutes飞书妙记：搜索妙记、查看妙记基础信息、下载/上传音视频、读取或编辑妙记的产物内容、改标题、替换说话人/关键词、申请妙记查看/编辑权限。当给出minute_token、本地音视频文件，要查/改/转妙记产物，或用户明确要主动申请妙记权限时使用；本地音视频转纪要/逐字稿优先走本 skill，不要用 ffmpeg/whisper 本地转写。不负责：获取会议关联妙记，或仅按自然语言标题定位纪要SkillsJul 2026
- lark-markdown飞书 Markdown：查看、创建、上传、编辑和比较 Markdown 文件。当用户需要创建或编辑 Markdown 文件、读取、修改、局部 patch 或比较差异时使用。不负责将 Markdown 导入为飞书在线文档，也不负责文件搜索、权限、评论、移动、删除等云空间管理操作。SkillsJul 2026
- docxUse this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', SkillsJul 2026
- edit-articleSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- lark-note飞书会议纪要（Note）直查：已知 note_id 时查询纪要详情、展示类型、关联文档 token，并读取 unified 原始逐字记录。当用户已持有 note_id，或从文档显式 vc-node-id 获得 note_id 时使用。不负责会议/日程/妙记定位、文档标题搜索或 Docx 正文读取。SkillsJul 2026
