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 stringslookback_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
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.
Check recent pipeline executions. For each app, invoke delivery:delivery-spinnaker to get recent pipeline execution history. Note any failed executions.
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.
Analyze failed executions. For any failed pipeline execution, invoke delivery:delivery-execution-failure-analysis with the execution ID to get EFA results.
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)
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.
Terminate. Report is complete when all sections are populated.
Design Principles
- 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.
- 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.
- 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
- Check Managed Delivery first. It gives the current state of what's deployed and what's pending. Pipeline history is supplementary.
- Always get canary details for failed canaries. "Canary failed" without scores is not actionable. Call the canary skill.
- Always get EFA for failed executions. "Pipeline failed" without EFA diagnosis is not actionable.
- Include Chap URLs. Every blocked deploy and failed canary includes the Chap URL from the API response.
- Check ALL apps, not a sample. Every configured app gets checked every run.
- Blocked deploys are the highest priority. They represent work that's stuck. Surface them first.
Anti-Rationalization Counter-Table
| Excuse |
Reality |
| "The deploy looks fine, I'll skip the canary details." |
If a canary failed or is pending, get the scores. "Looks fine" is not evidence. |
| "Pipeline failed but I didn't run EFA because the status is clear." |
EFA gives the root cause. Status gives the outcome. You need both. |
| "I checked the main app, the others are probably fine." |
Check ALL configured apps. A blocked deploy on a secondary app is still a blocked deploy. |
| "No Chap URL in the response, I'll skip the link." |
Chap URLs are in the delivery tool responses. Look for them in the constraint and verification fields. |
Termination Labels
| Label |
Meaning |
report_complete |
All apps checked, blocked deploys detailed, canary scores included |
report_partial |
Some apps checked but errors prevented full coverage |
no_apps_configured |
No apps specified — need config.json or user input |
api_error |
Spinnaker/Delivery API unreachable |
Self-Review Checklist
1---2name: deploy-status-report3description: Use when checking deployment status, Spinnaker deploys, canary results, what's deployed, pending rollouts, or generating a deployment report. Trigger phrases: deploy status, what's deployed, spinnaker status, canary results, deployment report, rollout status.4---56# Deployment Status Report78Produce an actionable report on Spinnaker deployment state using Delivery MCP tools.910## Configuration1112See [`_shared/report-config.md`](../_shared/report-config.md) for the standard config resolution pattern.1314**Config schema** (`~/.claude/skills/deploy-status-report/config.json`):15- `apps`: list of Spinnaker application name strings16- `lookback_days`: number (default: 7)1718**Required scope:** at least one `apps` entry.1920## Arguments2122- **apps**: list of Spinnaker application names to check23- **lookback_days**: how far back to check executions (default: match your cadence — 1 for daily, 7 for weekly)2425## Workflow26271. **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.28292. **Check recent pipeline executions.** For each app, invoke `delivery:delivery-spinnaker` to get recent pipeline execution history. Note any failed executions.30313. **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.32334. **Analyze failed executions.** For any failed pipeline execution, invoke `delivery:delivery-execution-failure-analysis` with the execution ID to get EFA results.34355. **Generate report.** Output markdown:3637```38## Deployment Status Report — {date}39Period: last {lookback_days} days | Apps checked: {N}4041### Summary42- Apps with blocked deploys: {count} | Failed canaries: {count} | Successful deploys: {count}4344### Blocked Deploys45(For each: app, what's blocked, constraint type, details, Chap URL)4647### Failed Canaries48(For each: app, canary score, failing metrics, analysis ID, Chap URL)4950### Failed Pipeline Executions51(For each: app, pipeline name, failure reason from EFA, execution link)5253### Successfully Deployed54(For each: app, current version, deploy time, regions)5556### Pending57(For each: app, pending version, waiting on what constraint)58```59606. **Deliver as HTML.** Follow the shared HTML delivery pattern in [`_shared/html-delivery.md`](../_shared/html-delivery.md). Report name: `deploy-status`. TLDR includes apps checked, blocked deploys count, and failed canaries count.61627. **Terminate.** Report is complete when all sections are populated.6364## Design Principles65661. **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.672. **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.683. **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.6970## Golden Rules71721. **Check Managed Delivery first.** It gives the current state of what's deployed and what's pending. Pipeline history is supplementary.732. **Always get canary details for failed canaries.** "Canary failed" without scores is not actionable. Call the canary skill.743. **Always get EFA for failed executions.** "Pipeline failed" without EFA diagnosis is not actionable.754. **Include Chap URLs.** Every blocked deploy and failed canary includes the Chap URL from the API response.765. **Check ALL apps, not a sample.** Every configured app gets checked every run.776. **Blocked deploys are the highest priority.** They represent work that's stuck. Surface them first.7879## Anti-Rationalization Counter-Table8081| Excuse | Reality |82|---|---|83| "The deploy looks fine, I'll skip the canary details." | If a canary failed or is pending, get the scores. "Looks fine" is not evidence. |84| "Pipeline failed but I didn't run EFA because the status is clear." | EFA gives the root cause. Status gives the outcome. You need both. |85| "I checked the main app, the others are probably fine." | Check ALL configured apps. A blocked deploy on a secondary app is still a blocked deploy. |86| "No Chap URL in the response, I'll skip the link." | Chap URLs are in the delivery tool responses. Look for them in the constraint and verification fields. |8788## Termination Labels8990| Label | Meaning |91|---|---|92| `report_complete` | All apps checked, blocked deploys detailed, canary scores included |93| `report_partial` | Some apps checked but errors prevented full coverage |94| `no_apps_configured` | No apps specified — need config.json or user input |95| `api_error` | Spinnaker/Delivery API unreachable |9697## Self-Review Checklist9899- [ ] All configured apps were checked100- [ ] Failed canaries have per-interval scores and Chap URLs101- [ ] Failed executions have EFA analysis102- [ ] Blocked deploys section appears first after summary103- [ ] Chap URLs present for all blocked/failed items104- [ ] Report has date header and app list noted105- [ ] HTML version uploaded to S3 with commuter link (unless `--no-html` or upload failed with noted fallback)106- [ ] Slack/chat delivery uses TLDR + link, not the full report
npow