Rig Release ยท diff
git:20261027.5ca9910 to git:20261027.8c1ba9d
14 added, 6 removed. Audit A to A.
---
name: Rig Release
- description: Assess release readiness with a version baseline from HEAD, full gates, and packaged file verification.
+ 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. **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.
- 7. **Compare versions.** Declared version must equal `HEAD` plus exactly one SemVer step unless the package is new. Record the comparison.
- 8. **Finalize.** Produce a readiness verdict with blockers and a human checklist.
+ 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, or push, even when every check passes.
+ - 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, blockers, and the remaining human steps.
+ Readiness verdict, proposed version, gate results, documentation state, package file list, release notes, migration notes, contributor reply drafts, blockers, and the remaining human steps.