danielrosehill/claude-sop-writer-plugin/bump-revision

bump-revision

Bump revision metadata across one or more SOPs.

Inputs to gather

1. 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)

1. Bump level — patch (default — 1.0 → 1.0.1), minor (1.0 → 1.1), or major (1.0 → 2.0).
2. Note (optional) — a short revision-note string to append to the doc's revision history block.
3. Recompile? (default yes) — after bumping, run compile on each affected doc and rebuild any binder that references it.

What to do

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

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

``typst #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.

1. If recompile: invoke compile for each updated .typ. If any of them belong to a binder defined in binders.yaml, also rebuild that binder.
2. 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.