Menu
Keep CI, pre-push verification, and release evidence tied to the current committed revision.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Validate, route, inspect, or run agent.3md manifests and typed tool templates.
Coordinate CorvidLabs agents through discovery, observation, execution, and verification.
Inspect spec ownership, drift, coverage, review queues, and gaps with fledge atlas.
Verify or record reviewed commit provenance, policy gates, and audit exports with fledge attest.
Assess working-tree, staged, range, or CI change risk and gates with fledge augur.
Build, modify, test, review, or release CorvidLabs Swift packages with Fledge-first and Swift 6 discipline.
| name | ci-release-hygiene |
| description | Keep CI, pre-push verification, and release evidence tied to the current committed revision. |
Use this skill when diagnosing CI, preparing a push, or deciding whether a release is ready.
First confirm the PR head and the revision that each CI run tested:
git rev-parse HEAD
git status --short --branch
fledge work status
A red run on an old commit is stale evidence, not a failure of the current local repair; a green run on an old commit is not approval for later changes. Say which case applies before acting.
Run the repository's relevant Fledge verification lane from the current committed tree (commit first when the lane must match what CI will see). Discover the lane—do not assume one command fits every project:
fledge run --list
fledge lanes list
fledge lanes run <verify-or-equivalent>
Keep the lane focused while iterating, and run the project-required full or release lane
before declaring a PR ready. When configured, deterministic risk gates (augur) and
provenance checks (attest) belong on the same SHA you intend to push.
Require evidence for the exact release candidate:
Do not tag from uncommitted work or rely on verification evidence produced before the
final release-candidate commit. Prefer the repository's fledge release flow and its verify/release-style lanes (discover
via fledge lanes list) when present—lane names are repository-defined, not universal.
After a release bump creates a new commit, re-verify that SHA—not the pre-bump tree.
Separate: local checks passed, CI running, CI failed on current head, and CI stale on a
previous head. Give one concrete next action rather than treating every CI transition as
a blocker. For private→public readiness, use public-release-audit.