signalproof-release

Governs whether an accepted artifact may be promoted by verifying identity, provenance, gates, and rollback.

Updated Aug 15, 2026
One-click install
npx skills add https://github.com/docreo/Signalproof-Skills --skill signalproof-release-docreo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: signalproof-release
Source: https://github.com/docreo/Signalproof-Skills/tree/main/skills/signalproof-release
Command: npx skills add https://github.com/docreo/Signalproof-Skills --skill signalproof-release-docreo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often ship artifacts that were rebuilt after testing, rely on evidence bound to a different build, or overstate readiness in release notes. This Skill enforces a release-governance boundary so only the exact accepted artifact, with provenance, rollback, and truthful claims, is promoted to a defined distribution scope. ## Core Features & Use Cases - Artifact Identity & Evidence Binding: Freezes candidate identity with SHA-256 digests, version metadata, and source commit, and blocks release when bytes change after acceptance. - Release Gate Matrix: Evaluates distinct gates (build, tests, verify, review, security, recovery, signing, owner acceptance, distribution authority) and returns a structured decision such as RELEASE READY, REVERIFY CANDIDATE, BLOCKED, or STOP. - Provenance, Rollback & Truthful Notes: Records supply-chain provenance, verifies the rollback target before promotion, and checks that release notes never claim more than the evidence supports. - Use Case: Before publishing a signed installer to beta users, run this Skill to confirm the signed bytes match the tested digest, the previous stable build remains recoverable, and the release notes accurately state scoped security results. ## Quick Start Ask the AI to evaluate whether the current build artifact is release-ready for a beta distribution using the signalproof-release gate matrix.

Frequently Asked Questions about signalproof-release

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

FAQPage Schema
How do I decide if a build artifact is ready to release?▼

Evaluate the exact candidate against a release gate matrix covering build, tests, verification, review, security, recovery, signing, and owner acceptance. The decision must bind all evidence to the artifact's immutable digest, not just its filename or source commit.

What happens if an artifact is rebuilt after acceptance testing?▼

A rebuilt, repacked, or re-signed artifact is treated as a new candidate whose evidence binding must be re-evaluated. You cannot release the new bytes using the old artifact's test evidence, even if the source code appears unchanged.

Does passing security review mean a release is approved?▼

No. A scoped security pass is only one input to the release decision. Release readiness also requires evidence binding, provenance, rollback verification, version coherence, truthful release notes, and explicit distribution authority.

Why must rollback be verified before promoting a release?▼

Promotion must never destroy or overwrite the last verified known-good state. The rollback target's identity, accessibility, and data compatibility are confirmed first so recovery remains possible if the release fails.

What are the limitations of a release-ready decision?▼

A release decision only proves the project-defined gates for the stated distribution boundary were satisfied. It does not establish legal compliance, universal compatibility, vulnerability-free status, or authorization for a broader deployment scope.