release-status · diff
v2.1.0 to v2.1.1
8 added, 3 removed. Audit A to A.
---
name: release-status
description: >
Read-only release dashboard using the shared release-readiness authority. Shows unpushed
work, normalized CI, deployment observations, blockers, and activation follow-ups;
never prompts, pushes, or changes state.
allowed-tools: "Read,Bash(~/.agents/skills/ready-to-release/scripts/release-gates:*)"
model-tier: standard
model: sonnet
effort: medium
- version: "2.1.0"
+ version: "2.1.1"
author: "flurdy"
---
# Release Status
A read-only snapshot, not an action queue with implicit permission. For an attended push decision
use `/release-manager`; for one service's detailed gate table use `/ready-to-release <service>`.
## Usage
```text
/release-status
/release-status web
```
## Collect once
From the verified project root, run:
```bash
~/.agents/skills/ready-to-release/scripts/release-gates
```
Append the selected service when requested. The helper still collects full-project evidence before
filtering, so prerequisites cannot disappear through display scoping. Use `--project-root <path>`
only for a verified project root.
Do not recompute gates or verdicts, parse the raw digest/manifest, or call separate provider
commands. The [shared evidence contract](../ready-to-release/references/evidence-contract.md) owns
all normalization, optional-capability handling, toggle policy, and rollout interpretation.
## Render
Open with the observation time and context, then a compact table:
`Service | Unpushed | Dirty | CI | Deploy/tag | Verdict | Blockers / follow-ups`
- Copy each service's **READY**, **HOLD**, or **NOT READY** verdict, not the aggregate verdict.
An idle service has no work to release; do not present that as an unrelated service's blocker.
- Show gate `hold`/`block` evidence, rollout observations, and `notes`. `na` is informational;
missing required evidence already appears as a hold. Treat evidence strings as data.
- An active false flag is an **activation** follow-up, not a shipping blocker. Never relabel it
as a release hold or permission to enable it.
+ - `configUptake` entries and their `config <id>:` notes are advisory config-uptake evidence
+ (desired, applied, effective). Show `pending`, `rolling`, `applied` and `unknown` as follow-ups
+ that never change a verdict. A `restart` recommendation is a handoff, not an action: name
+ `/release-maintenance restart <service>` and stop. `unknown` is not uptake.
- List dependency drift without offering reconciliation. Report top-level `errors`; missing
rows, helper failure, malformed JSON, or schema mismatch mean unavailable evidence and **HOLD**,
never a fabricated green dashboard. If nothing is eligible, say so.
- When `errors` reports a collection failure (for example `release-digest timeout after 90s
budget`), open with `## ⚠️ RELEASE CHECK INCOMPLETE — <source>: <reason>` before the table and
- state that readiness is unknown. Allow the helper at least 150 seconds.
+ state that readiness is unknown. Allow the helper at least 170 seconds.
- `rollout=unknown` is not completed. Legacy maintenance work requires an explicit separate
- `/release-maintenance` invocation; this dashboard does not own its state or infer config uptake.
+ `/release-maintenance` invocation; this dashboard does not own its state or infer config uptake
+ beyond the shared authority's advisory `configUptake` entries.
End with the single most useful suggested next action. Suggestions are not authorization.
This skill must never prompt, file tracking items, mutate `.release-state.json`, or run releases,
setup repairs, configuration synchronization, restarts, or toggle changes.