release-status v2.1.1A

Immutable. This exact content never changes and is served at /api/v1/blob/13e251d4e885966d.

---
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.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 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
  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.