ready-to-release — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited ready-to-release (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
A focused, per-service readiness gate. Where /release-manager scans everything and prompts, this answers one question thoroughly: is `<service>` safe to ship right now? Read-only — it reports a verdict, it does not push.
This is the deploy-side cousin of /ready-to-merge (which gates a PR merge). This gates a release of an already-merged service: built locally, CI green, contracts honoured, deploy order respected, toggle in place.
/ready-to-release dispatchA service argument is required.
Run these checks for the named service and present a gate table (✅ / ⚠️ / ❌ per row):
make git-status <service>. Show commits ahead (N) and whether thetree is dirty (*). N = 0 → nothing to release (note it and stop). Dirty tree → ⚠️ (commit first). List the unpushed commits with ./scripts/mgit log <service> --oneline @{u}..HEAD.
make ci-status <service>. success → ✅; running → ⚠️ (wait); failed/error→ ❌ (blocker); unknown (no CIRCLECI_TOKEN) → ⚠️.
Skill /contract-check status andread the rows for this service. Covers both contract state (staleness / unsynced / uncommitted → ❌) and verification coverage — if this service is a provider with a coverage GAP (CI doesn't verify all its consumer pacts, e.g. commented-out consumers), flag ⚠️ (a contract change may break an unverified consumer).
./scripts/pact-graph (a project symlink installed by/release-manager — see its Setup if missing) and read docs/release-manifest.yaml. Build the effective dependency map = (order.derived ∪ order.manual) − order.suppress, and take this service's prereqs. A prereq blocks only if it is co-changing — has unpushed commits, is mid-rollout (make deploy-status <prereq> shows a Deployment N/M, N<M, or a CronJob service — digest/patrol/reconciler — showing cron:rollout), or was pushed-but-not-rolled. A stable, already-live prereq (a Deployment 1/1 at current tag, or a CronJob service showing the settled cron marker) does not block. All clear → ✅; any co-changing prereq → ❌ (waiting on <prereq>). (Contract coverage is checked in step 3, not here — this step is purely deploy ordering.)
docs/release-manifest.yaml toggles has an entry whose serviceis this one, report the flag, its live value (make feature-toggles), and the flip_when condition so you know whether shipping needs a follow-up toggle flip. Missing-but-expected toggle → ⚠️. A toggle with status: dark-release means the service is in a shadow launch — report it as 🌓 dark-release (flip is a later manual call), not a blocker. If the service has a parked flag, note it as informational only (deliberately off, superseded_by / reconsider_if) — never treat it as a pending flip.
make deploy-status <service>: show current ready/tag/age so you can seewhat's running versus what you're about to ship. For a CronJob service (digest/patrol/reconciler) this is the cron/cron:rollout marker + tag + last-run age, not replicas.
End with one line:
make git-push <service> (the user runs it, or use /release-manager).
Read-only: never push here. Pushing is an explicit action via /release-manager or make git-push.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.