Deployment Status Report

Produce an actionable report on Spinnaker deployment state using Delivery MCP tools.

Configuration

See _shared/report-config.md for the standard config resolution pattern.

Config schema (~/.claude/skills/deploy-status-report/config.json):

• apps: list of Spinnaker application name strings
• lookback_days: number (default: 7)

Required scope: at least one apps entry.

Arguments

• apps: list of Spinnaker application names to check
• lookback_days: how far back to check executions (default: match your cadence — 1 for daily, 7 for weekly)

Workflow

1. Check Managed Delivery status. For each app, invoke delivery:delivery-managed-delivery to get current deployed versions, pending deploys, constraint state (canary, deploy windows, depends-on), and verification results.
2. Check recent pipeline executions. For each app, invoke delivery:delivery-spinnaker to get recent pipeline execution history. Note any failed executions.
3. Get canary details for failures. For any app with a failed canary constraint, invoke delivery:delivery-managed-delivery-canary to get per-interval scores and region breakdown.
4. Analyze failed executions. For any failed pipeline execution, invoke delivery:delivery-execution-failure-analysis with the execution ID to get EFA results.
5. Generate report. Output markdown:

## Deployment Status Report — {date}
Period: last {lookback_days} days | Apps checked: {N}

### Summary
- Apps with blocked deploys: {count} | Failed canaries: {count} | Successful deploys: {count}

### Blocked Deploys
(For each: app, what's blocked, constraint type, details, Chap URL)

### Failed Canaries
(For each: app, canary score, failing metrics, analysis ID, Chap URL)

### Failed Pipeline Executions
(For each: app, pipeline name, failure reason from EFA, execution link)

### Successfully Deployed
(For each: app, current version, deploy time, regions)

### Pending
(For each: app, pending version, waiting on what constraint)

6. Deliver as HTML. Follow the shared HTML delivery pattern in _shared/html-delivery.md. Report name: deploy-status. TLDR includes apps checked, blocked deploys count, and failed canaries count.
7. Terminate. Report is complete when all sections are populated.

Design Principles

1. Team-level only. Aggregate to team level — it is the right granularity for a periodic digest. Individual-level detail (commits per person, PR count per author) is too noisy for a team report.
2. Deterministic math first, LLM narrates only. All classification (severity, flaky vs broken, pass/fail) must be computed deterministically from data. The LLM writes prose around the numbers but never assigns severity or makes classification judgments.
3. Pair metrics with counter-metrics. Never report velocity without stability. If showing deploy frequency, also show change failure rate. If showing PR throughput, also show rework rate.

Golden Rules

1. Check Managed Delivery first. It gives the current state of what's deployed and what's pending. Pipeline history is supplementary.
2. Always get canary details for failed canaries. "Canary failed" without scores is not actionable. Call the canary skill.
3. Always get EFA for failed executions. "Pipeline failed" without EFA diagnosis is not actionable.
4. Include Chap URLs. Every blocked deploy and failed canary includes the Chap URL from the API response.
5. Check ALL apps, not a sample. Every configured app gets checked every run.
6. Blocked deploys are the highest priority. They represent work that's stuck. Surface them first.

Anti-Rationalization Counter-Table

Termination Labels

Self-Review Checklist

• All configured apps were checked
• Failed canaries have per-interval scores and Chap URLs
• Failed executions have EFA analysis
• Blocked deploys section appears first after summary
• Chap URLs present for all blocked/failed items
• Report has date header and app list noted
• HTML version uploaded to S3 with commuter link (unless --no-html or upload failed with noted fallback)
• Slack/chat delivery uses TLDR + link, not the full report