Rig Release git:20261027.8c1ba9dA

Immutable. This exact content never changes and is served at /api/v1/blob/e85a35bdaf02285f.

---
name: Rig Release
description: Assess release readiness with a version baseline from HEAD, full gates, packaged file verification, and read-only release-note, migration, and contributor-reply drafts.
---

# Rig Release

> Read [Evidence rules](../../references/evidence.md).

> This workflow never publishes, tags, pushes, or mutates a remote. Publication stays human-owned.

## Workflow

1. **Read the baseline from HEAD.** Do not use an uncommitted version. For this plugin family, `package.json` is the version manifest; confirm the repository's policy for the package being released.
2. **Classify the change.** Fix or wording: patch. New capability or surface: minor. Breaking contract: major, and only with explicit approval.
3. **Start the run.** `rig_evidence` with `action: "start"`, `skill: "rig-release"`, and the package root.
4. **Run the full gate set.** `rig_gate` with `action: "run"` and no name filter. A single failure blocks readiness; do not retry unchanged.
5. **Synchronize documentation.** Verify the changelog bullet describes user-visible impact, the README version marker matches the manifest, and changed agents, skills, tools, and commands are documented.
6. **Draft the release pack.** Bind the commit range with `rig_evidence` `action: "record"` and `commit`, then produce the three drafts below from that evidence. Every line must trace to a commit, finding, or changelog entry; an empty section is better than an invented one.
7. **Verify the package.** Run the package build or `npm pack --dry-run` (or the project equivalent) and check the file list. No tests, plans, credentials, or private evidence may ship.
8. **Compare versions.** Declared version must equal `HEAD` plus exactly one SemVer step unless the package is new. Record the comparison.
9. **Finalize.** Produce a readiness verdict with blockers, the drafts, and a human checklist.

## Release pack

- **Release notes.** Group by Added, Changed, Fixed, Security, Deprecated, and Removed. Each entry names the user-visible effect, not the internal refactor, and credits the contributor when the commit or issue records one.
- **Migration notes.** List breaking changes, renamed options, changed defaults, and required user actions, each with before/after snippets and a rollback path. Say explicitly when no action is required.
- **Contributor replies.** Draft a short factual reply per linked issue or pull request: what shipped, what did not, and what happens next. Never promise a date, never claim a fix that is not in the range, and never post it.

## Rules

- A dirty working tree is not a blocker for assessment, but it must be disclosed; the released commit must be clean.
- Never bump a version skips a step or down from `HEAD`.
- Do not publish, tag, push, comment, or open a pull request, even when every check passes. Drafts stay in the report.
- Never invent a changelog entry, contributor, issue link, or migration step. Missing evidence is a blocker, not a blank to fill.
- Report unavailable evidence as a blocker, not a pass.

## Output

Readiness verdict, proposed version, gate results, documentation state, package file list, release notes, migration notes, contributor reply drafts, blockers, and the remaining human steps.