coferlandia-release-publisher

Publishes exact Git commits as annotated tags and verified GitHub Releases.

Updated Jun 11, 2026
One-click install
npx skills add https://github.com/coferlandia/coferlandia-skills --skill coferlandia-release-publisher-coferlandia
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: coferlandia-release-publisher
Source: https://github.com/coferlandia/coferlandia-skills/tree/main/skills/ops/coferlandia-release-publisher
Command: npx skills add https://github.com/coferlandia/coferlandia-skills --skill coferlandia-release-publisher-coferlandia

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Turning an exact Git commit into a formal, externally observable release is error-prone: tags get misplaced, GitHub Releases drift from their tags, partial publications are hard to resume, and version numbers get chosen without evidence. This Skill provides a deterministic, fail-closed Commit -> Release workflow with dry-run planning, idempotent recovery, and machine-readable verification. ## Core Features & Use Cases - Deterministic release planning: Inspect a target commit, classify SemVer impact from evidence, and produce a sealed JSON dry-run plan before any remote mutation. - Fail-closed publication: Create the annotated tag first, push without force, create a draft GitHub Release, upload and verify artifacts/provenance, then publish and re-verify. - Idempotent recovery and verification: Resume correct partial states (tag-only or matching draft), reject inconsistent tag/release identity, and resolve version -> tag -> exact SHA for downstream automation. - Use Case: You need to cut release v1.7.0 from a specific commit on a maintenance branch. Run inspect and plan to review the exact operations, then publish the reviewed plan and resolve the release as JSON for your CI/CD pipeline. ## Quick Start Ask the agent to dry-run and then publish a GitHub release for a specific commit using the coferlandia-release script with an explicit SemVer version, title, and release notes file.

Frequently Asked Questions about coferlandia-release-publisher

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I publish a GitHub Release from a specific Git commit?▼

Run the CLI's inspect command against the target revision, then plan with an explicit SemVer version, impact, title, and notes file to produce a sealed JSON dry-run. After reviewing the plan, run publish with that plan file to create the annotated tag, draft release, and verified publication.

How do I release an older commit or a hotfix branch?▼

Pass the older commit as the --target revision; eligibility is based on the exact commit being reachable from an allowed release ref, not the current checkout. Maintenance or hotfix lines are declared through release_refs in the repository's release policy JSON.

Does this release workflow support SemVer prereleases?▼

Yes, SemVer prereleases such as 1.7.0-rc.1 are supported and must be published with the GitHub prerelease flag set. The CLI validates that the prerelease flag matches the version's prerelease identifier and that the version does not understate the declared impact.

What happens if a release publication fails halfway?▼

Partial states are resumable: a correct tag-only state resumes at draft creation, and a matching draft resumes at asset verification and publication. Conflicting tag, release, or provenance identity is classified INCONSISTENT and fails closed rather than being silently repaired.

Can this skill deploy the release after publishing?▼

No, publication ends at verified tag plus GitHub Release state. Deployment, service restarts, rollbacks, and production migrations are explicitly out of scope and belong to a separate deployment authority; the resolve command only emits release identity for downstream systems.

Why does release verification fail on an existing tag?▼

Verification fails when the tag is lightweight instead of annotated, peels to a different commit than the release, or when assets or the provenance manifest disagree with the planned digests. The publisher never moves or recreates published identity to hide such drift.