documentation

name	documentation
description	Updates CHANGELOG.md and inline docs to reflect a recent code change. Invoke after implementing a feature or fix — describe what changed or paste the diff.
argument-hint	["description of what changed or paste diff"]

Update the documentation to reflect recent code changes. Fast, accurate, no fluff.

---

Step 1 — Understand the change

The user will describe what changed, or paste a diff. If neither is provided, ask: "What changed? Paste the diff or describe it."

Don't proceed until you know what changed.

---

Step 2 — Read before you write

Before touching any documentation:

• Read the actual code for any file mentioned in the change
• If existing docs describe behaviour in that file, check whether they still match
• If they don't match: update the docs to match the code, not the other way around

The code is truth. Docs are descriptions of the code.

---

Step 3 — Update CHANGELOG.md

Add an entry under ## [Unreleased] (create the section if it doesn't exist).

## [Unreleased]

### Added
- [User-facing description of net-new feature or capability]

### Changed
- [User-facing description of changed behaviour or interface]

### Fixed
- [User-facing description of bug that was fixed]

### Security
- [Security fix description — include CVE if applicable]

### Removed
- [What was removed and what to use instead]

Only include categories that apply.

Entry rules:

• One line per change, starting with a verb: "Add", "Fix", "Remove", "Update"
• User-facing language — describe what the user sees, not the internal implementation
• Omit internal refactors, variable renames, and code cleanups unless they affect behaviour or API

---

Step 4 — Update inline docs (only if broken)

If the change modified the signature, behaviour, or usage of a function/component that has a JSDoc or inline comment, update that comment. Don't touch docs that are still accurate.

Do not add JSDoc to functions that don't have it.

---

Rules

• Don't invent changelog entries. Only document what actually changed.
• Don't pad. One line per change.
• Ask once if intent is unclear. If you can't tell whether a change is user-facing or internal, ask before writing.
• No "Improvements to internal architecture." If it's internal, it doesn't go in the changelog.