finalize

---
name: finalize
description: Prepare a release, cut it, and hand it over — docs, release notes, CI gates, rollback plan, and monitoring — without publishing anything the user has not approved. Use when the work claims to be complete and ready to publish. Only invoke via the orcinus router.
license: MIT
user-invocable: false
---

# FINALIZE — ready to publish, and provably so

Prepare the release and hand it over. Do not publish, merge, or tag anything until the user confirms in writing. Use the ready tools as-is — do not rewrite them, and never claim one ran when it did not.

## Rules

- No publish without explicit human confirmation. No auto-merge, no auto-publish, no auto-tag.
- No claim without evidence. Every item in the release report points to a command, an output, or a file.
- Use ready tools as-is. Record each tool with its version, or "not run" with the reason.
- A check that did not run is never reported as passed.

## Steps, in order

### 1. Prerequisites

Confirm orcinus-verify gave PASS and security-review gave PASS (or explicit exceptions) on the change. If either is FAIL or INCOMPLETE, stop and fix that first. Finalize does not override verification or security.

### 2. Docs and handoff

Use the installed `handoff` skill as-is. Write the handoff: what changed, how to run the project, what is next, what is blocked, and what must not be forgotten. Do not rewrite handoff; use it.

### 3. Release notes — use release-please as-is

Use release-please (googleapis/release-please, Apache-2.0, CLI + GitHub Action) as-is to generate release notes from conventional commits. Do not hand-write notes when release-please can generate them. If release-please is not set up in the project, record "not run — release-please not set up" and write the notes by hand from the git log, marking them as hand-written. Never claim release-please ran when it did not. Note: release-please does not publish to package registries; registry publishing is a separate step, not covered here.

### 4. CI gates

Re-run the four commands (build, lint, typecheck, test) and record their outputs. Use Waza (`skills/waza`, microsoft/waza, MIT, CLI) as-is for graded eval scenarios when the project has them (the repo ships a runnable example, `waza-orcinus-verify`, for a full-repo install). Record each result with its tool and version, or "not run" with the reason.

### 5. Release checklist

Write down, with evidence for each item:

- Version bumped (name the version).
- Release notes (generated or hand-written, and which).
- Docs updated.
- Rollback plan: how to revert, who does it, and how long it takes. A release without a rollback plan is not ready.
- No secrets in the release, no failing checks.

### 6. Monitoring after publish — use the ready skills as-is

Two skills cover monitoring, and they are complements, not substitutes. Use `monitoring` (injected verbatim, MIT — see its ATTRIBUTION.md) for the outside view: uptime probes on the critical journey, `/livez` split from `/readyz`, SLO burn-rate alerts with two windows, on-call escalation with a runbook per alert. Use `monitoring-observability` (injected verbatim, MIT, OrchestKit — see its ATTRIBUTION.md) for the telemetry side: Prometheus, Grafana, Langfuse, or LLM tracing. When the project uses neither (for example, a library with no runtime), say so plainly and record that the project has no runtime to monitor. Do not claim monitoring exists when it does not.

### 7. Gate: Code → Done / Publish

Stop here. Present the release report (below) and ask the user to confirm it in writing. Do not publish, merge, or tag until they confirm. If they change anything, update the report and confirm again.

### 8. After publish

New issues go through bug triage. The ready skill for that is issue-triage (MIT, copied verbatim into this repo — see its ATTRIBUTION.md). Record new issues in the project's tracker with the same evidence standard: what broke, how to reproduce it, and what the last known-good version was.

## Release report

Return the report in this form, no more, no less:

- Version.
- Release notes (generated by release-please, or hand-written from the git log — and which).
- Verification: orcinus-verify verdict, security-review verdict, four commands with outputs. A security-review verdict of PASS WITH LIMITATIONS is not a PASS: list each limitation, say whether it blocks the release, and record the user's decision on each one before confirming.
- CI gates (Waza, if run).
- Rollback plan.
- Monitoring plan (monitoring for the outside view, monitoring-observability for telemetry, minimal signals, or no runtime — and which).
- Handoff (what changed, how to run, what is next, what is blocked).
- What was explicitly not published, and why.

## Sources

This skill is an orchestrator. It uses ready tools as-is: release-please (googleapis/release-please, Apache-2.0, licence verified from the primary LICENSE file); Waza (microsoft/waza, MIT); handoff (installed, MIT); monitoring-observability (yonatangross/orchestkit, MIT, injected verbatim — see its ATTRIBUTION.md). No text was copied from release-please, Waza, or handoff. Issue-triage is copied verbatim (MIT — see its ATTRIBUTION.md).