velocity.report: Skill for Claude Code

Skill: devlog-update

Bring docs/DEVLOG.md up to date by reading git history across all branches and synthesising new entries in the established format.

Usage

/devlog-update

Format reference

The devlog uses one H2 header per UTC date:

## April 7, 2026 - Short Theme Title

- Concise bullet describing what changed and why (#512).
- Another bullet. References files in `backticks`, links to [design docs](plans/foo.md) (#513, #514). <!-- link-ignore -->
- {branch-name} Unlanded work on a feature branch.

The register rules (one line per bullet, one heading per day, PR numbers) are canonical in .github/STYLE.md under "Logs and registers"; this skill applies them.

Conventions

• Date format: Month DD, YYYY (e.g. April 7, 2026).
• Separator: - (hyphen) between date and theme. Never use em-dashes in headers.
• Branch metadata: unlanded bullets begin with {branch-name} (the branch slug in curly braces, immediately after - ). No italic _Branch:_ headers. This is the only format for denoting branch work.
• Bullet style: each bullet is exactly one physical line starting - . Never hard-wrap a bullet, however long: no indented continuation lines. Concise, action-focused, past tense.
• Content per bullet: what changed, which files/packages/layers, why, and references to design docs or PRs where relevant.
• Ordering: newest entry first (prepend to the file, after its introduction and formatting note).
• One heading per date: exactly one ## heading per UTC calendar day that has work. No date ranges (February 9-10) and no second heading for a day that already has one: append to that entry and broaden its theme title instead. Merge related commits into themed bullets rather than listing every commit individually.
• PR references: every main-landed bullet ends with the number(s) of the PR(s) that delivered it, before the final full stop: (#622) or (#605, #606). No "Merged as" or "merged to main" phrasing. Add file count only when notable. Work pushed straight to main without a PR has no number.
• Links: link to plan docs only when the entry is primarily about creating or updating that plan. Do not link every file mentioned.
• Version bumps: include only for actual releases. Omit pre-release bump bullets.
• Tone: factual, developer-journal style. No marketing language. Record decisions and rationale when non-obvious.