Skill

bump-revision

Update revision date and version metadata across one or many SOPs in the current project, then optionally recompile. Reads the Typst frontmatter (or a leading metadata block) of each target document, increments the revision (semver-style: minor by default, patch/major on request), updates the date to today, and writes back. Use when the user has reviewed a set of procedures and wants to mark them as a fresh revision.

npx claudepluginhub danielrosehill/claude-code-plugins --plugin sop-writer

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Bump revision metadata across one or more SOPs.

SKILL.md

Similar Skills

using-superpowers

180.9k

Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.

3 files

superpowers

Stats

Stars1

Forks0

Last CommitApr 30, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

bump-revision

Bump revision metadata across one or more SOPs.

Inputs to gather

Targets — one of:

A specific file path
A glob (sops/*.typ)
A binder name from binders.yaml (bumps every doc in that binder)
all — every .typ SOP in the project (confirm before doing this)

Bump level — patch (default — 1.0 → 1.0.1), minor (1.0 → 1.1), or major (1.0 → 2.0).

Note (optional) — a short revision-note string to append to the doc's revision history block.

Recompile? (default yes) — after bumping, run compile on each affected doc and rebuild any binder that references it.

What to do

Resolve targets to a concrete file list. Confirm with the user if all was requested or the list is large (>10 files).

For each file:

Parse the leading metadata. Plugin convention is a Typst block at the top:

#let meta = (
  title: "Rocket & Missile Alert Response",
  revision: "1.2",
  date: "2026-04-01",
  audience: "household members",
  source: "Home Front Command",
)

Bump revision per the requested level.
Set date to today's ISO date.
If a revisions: history list exists, append (version: "<new>", date: "<today>", note: "<note>").
Write back.

If recompile: invoke compile for each updated .typ. If any of them belong to a binder defined in binders.yaml, also rebuild that binder.

Print a summary: which files were bumped (old → new version), and which PDFs were regenerated.

Notes

Be conservative parsing the metadata block — if a doc doesn't follow the convention, skip it and report it; don't try to invent metadata.

The metadata convention is plugin-recommended, not required. Documents without it are still valid SOPs; they just opt out of bump-revision.

Revision strings are free-form in the source — common patterns: "1.0", "2024.04", "r3". Prefer semver-ish but accept whatever's already there and increment numerically where possible. If unparseable, ask.

bump-revision

Bump revision metadata across one or more SOPs.

Inputs to gather

Targets — one of:
- A specific file path
- A glob (sops/*.typ)
- A binder name from binders.yaml (bumps every doc in that binder)
- all — every .typ SOP in the project (confirm before doing this)
Bump level — patch (default — 1.0 → 1.0.1), minor (1.0 → 1.1), or major (1.0 → 2.0).
Note (optional) — a short revision-note string to append to the doc's revision history block.
Recompile? (default yes) — after bumping, run compile on each affected doc and rebuild any binder that references it.

What to do

Resolve targets to a concrete file list. Confirm with the user if all was requested or the list is large (>10 files).
For each file:
- Parse the leading metadata. Plugin convention is a Typst block at the top:
```
#let meta = (
  title: "Rocket & Missile Alert Response",
  revision: "1.2",
  date: "2026-04-01",
  audience: "household members",
  source: "Home Front Command",
)
```
- Bump revision per the requested level.
- Set date to today's ISO date.
- If a revisions: history list exists, append (version: "<new>", date: "<today>", note: "<note>").
- Write back.
If recompile: invoke compile for each updated .typ. If any of them belong to a binder defined in binders.yaml, also rebuild that binder.
Print a summary: which files were bumped (old → new version), and which PDFs were regenerated.

Notes

Be conservative parsing the metadata block — if a doc doesn't follow the convention, skip it and report it; don't try to invent metadata.
The metadata convention is plugin-recommended, not required. Documents without it are still valid SOPs; they just opt out of bump-revision.
Revision strings are free-form in the source — common patterns: "1.0", "2024.04", "r3". Prefer semver-ish but accept whatever's already there and increment numerically where possible. If unparseable, ask.