/ln-62-release-publisher

name: ln-62-release-publisher
description: "Prepares and publishes an explicitly requested tagged GitHub release; does not deploy applications."

Release Publisher

**Goal:** Prepare a reproducible release and publish it only after the user approves the exact tag and notes.

**Execution contract:** Track every checklist item as `PENDING`, `PROVEN` with observed outcome evidence, `CLEARED` with evidence its condition is absent, or `UNPROVEN` with a gap. Reading, delegation, tool failure, zero exit status, and self-reported success are not proof. Reconcile after each section; before returning, resolve all `PENDING`, count only `PROVEN` and `CLEARED`, and apply verdict and approval rules to every gap. Preserve intent, scope, mode, and existing authorization. Complete authorized work before required external approval; ask only consequential unresolved choices. If nobody can answer, report the exact question and apply the skill's gap verdict without waiting or guessing. Cite any blocking instruction and unresolved boundary; never invent approval gates. Scale depth to material risk; preserve mandatory checks, dependencies, and safety order while choosing verification methods. Accept equivalent user or repository evidence without requiring another skill, named artifact, or full lifecycle. Preserve source requirement and decision IDs. Bind reused evidence to relevant versions, dirty changes, configuration, environment, and observation windows; invalidate only affected claims. Choose the primary workflow by outcome and explicit selection. Consume neighboring contracts and valid evidence without duplicating ownership or restarting audits. Split distinct deliverables by scope, not mandatory skill invocation. Broad independent assessments use audit workflows; focused domain reviews remain read-only. On continuation, reconcile task, authorization, state, and gaps. Return a compact continuation record for long work or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority. Trace applicable requirements to their authoritative owner, planned or implemented change, acceptance evidence and status in the existing artifact or response; no new registry is required. Explicit constraints remain binding until an authorized deviation; risk determines priority, not permission to ignore them. Investigate the causal flow beyond initially named files. Within implementation authority, include structural repair needed for the outcome; minimize total complexity and risk, not changed lines. This does not authorize unrelated cleanup or mutation during review. Before retrieval, define the evidence question; read selectively without skipping applicable instructions. Use tools for mechanical processing; summarize bounded results, errors, coverage, and source paths, keeping full output outside context. Before technical decisions, establish applicability and actual versions; verify version-dependent assumptions against official documentation or specifications. Search and read primary pages for current external recommendations; snippets are not evidence. Version-matched bundled documentation or valid prior evidence suffices. Record decision, version, source, and limitations. Mark unavailable evidence UNVERIFIED; block only essential dependent work. Prefer native mechanisms, justify added tools or abstractions with evidence, and reuse the existing rule owner.

Tool Routing

| Need | Preferred capability | Fallback | |---|---|---| | Release boundary and commit evidence | Git history, tags, and diffs | Hosting API commit comparison | | Existing release style and state | Authenticated GitHub CLI or connector | Public GitHub API for read-only evidence | | Release identity and version scope | Repository policy, prior tags, and canonical version files when present | Stop only when the release identity remains ambiguous | | Release validation | Repository-native gates and clean checkout | Manual structural checks with reduced confidence | | Tag and GitHub Release creation | Git plus an authenticated GitHub release capability | `BLOCKED`; do not emulate release state in files | | Installation verification | Isolated environment against the documented distribution source | Clean source validation without install proof |

When publishing through a shell, use a temporary notes file so Markdown, quotes, and code blocks are not reinterpreted. Keep credentials in the host credential store and never echo them.

Do not browse for generic release advice when repository policy and previous comparable releases answer the question. Use official host documentation only for current API or CLI behavior.

Checklist

Establish scope and evidence

• [ ] Confirm the user explicitly requested a release and identify the repository, release target, and intended audience.
• [ ] Read repository release rules before selecting a version, tag shape, files, or publication sequence.
• [ ] Verify an authenticated GitHub release capability, repository access, and permission to create releases.
• [ ] Require a clean worktree or explicitly exclude unrelated changes before release preparation.
• [ ] Fetch tags and the target branch; confirm local HEAD is synchronized with the remote release branch.
• [ ] Resolve the prior release boundary for this release line; for a first release, use the agreed initial history boundary and label it explicitly.
• [ ] Inspect commits and full commit bodies from the previous release boundary to the proposed release commit.
• [ ] Read the affected manifests, authoritative documentation, installation instructions, configured catalogs, and user-facing migration notes when present.
• [ ] Treat commits and source diffs as evidence; use existing release notes only as secondary context.

Version and Scope

• [ ] Use the repository's declared versioning policy; do not impose CalVer, SemVer, or a shared catalog version wh