ppt-release

Run this repo's shipping and releasing checklist on a pending change, then tag and publish once confirmed.

Goal

Make "prepare and ship a release" a single deliberate command instead of re-deriving the shipping and releasing checklist by hand every time. It runs the existing quality gates (sip, re0-git) when they're installed, and applies their checks directly when they aren't. It treats "commit" and "tag + push" as two separately-staked moments: a commit stays local and reversible, tag + push is the one step that goes public.

Workflow

1. Confirm shipping readiness against the pending diff — every applicable item from CLAUDE.md's Shipping checklist except the version bump and the sip run, which are steps 2 and 3 here:
   • any new or changed SKILL.md has the right shape (frontmatter name+description, disable-model-invocation only if user-invoked, body sections Goal/Workflow/Rules/Verification);
   • the README, and every localized copy under docs/readme/, lists or describes it accurately, with the right Invoker column;
   • plugin.json registers its path;
   • any rename appends an old -> new row to ppt-upgrade's deprecations checklist, in release order;
   • shared cross-skill rules (edit-safety, negatives-as-corpus, commit-economy) stay coherent across every copy that carries them. Report any gap and stop rather than guessing past it.
2. Classify the version bump: a new skill is minor; a fix or docs-only change is patch; a skill removed with no replacement path is major. State the classification and why.
3. Run sip if it is installed, and apply its findings. If it is not installed, run its checks directly in order — cold-read (shower), truth checks only when there is a claim or an eval (factchk/mandela), consistency (ssotchk/ssotize), then tidy (re0) — and apply what they find.
4. Bump package.json's version to the classification from step 2.
5. Draft the commit message to commit-economy from the first draft: one bullet per real, durable fact; nothing the diff or version already proves; no co-author tag; matched to the local log's own shape, not appended to across edits. If a commit already exists and needs cleanup, re0-git (if installed) rewrites it the same way.
6. Ask for explicit confirmation, then commit.
7. Write .ppt/release/RELEASE_NOTES.local.md — a gitignored, never-shipped local scratch file that rides the signed tag as its message — to this house style: one ## heading naming the release's durable idea, not the version; one short present-tense paragraph of what is true now; only the sections the release earns (### New, ### Also, ### The catalog (N skills) only when the roster needs re-mapping, ### Install always last as an indented block); skill names and paths in backticks; nothing the tag or version already proves.
8. Ask for a second, separate confirmation before tagging and pushing — this is the one step that goes public. Then: git tag -s vX.Y.Z -F .ppt/release/RELEASE_NOTES.local.md --cleanup=verbatim, push main, push the tag.
9. Watch the triggered release workflow to completion; report success or the actual failure, never assume it landed.

Rules

• Never invent or assume a CLI command or flag; verify it against official docs or a real run before writing it into a step you will execute.
• If the pending diff mixes unrelated concerns, say so and propose a split before drafting a message — don't let one commit's message do a diff's job.
• Never push before the local version match holds (package.json equals the tag about to be created); the CI check is a backstop, not the first line of defense.

Verification

Before finishing:

1. package.json's version matches the tag.
2. The commit message reads as a clean handoff on its own, without the diff.
3. Release notes follow the house style and mention only what this release earns.
4. The pushed tag's triggered workflow run completed successfully — confirmed, not assumed.
5. Report any skipped step or unresolved gap.