Use delivery-metrics-report

Produce a delivery metrics report for one service from deployment, incident and pull-request exports

Produce a delivery metrics report for one service from deployment, incident and pull-request exports — the DORA metrics (deployment frequency, change lead time, change fail rate, failed deployment recovery time) plus flow metrics (WIP, cycle time p50/p85, throughput), computed by a script with per-week trends and explicit data gaps, then interpreted for what changed and why.

Reach for it when the user wants DORA metrics, says "how are we doing on the four keys", "what's our change failure rate", "compute lead time and deploy frequency from this CSV", or "build our delivery metrics report".

Install it

npx skilldrop-cli install delivery-metrics-report                 # Claude Code, your user folder
npx skilldrop-cli install delivery-metrics-report --project       # Claude Code, this repo
npx skilldrop-cli install delivery-metrics-report --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the SRE / on-call pack: --pack sre-oncall installs it with its neighbours.

It ships scripts, so it needs Python 3 (standard library only, nothing to install). What they may touch is declared in its manifest.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Compute our four DORA metrics from this deployments CSV and incident export"
• "What's our change failure rate and lead time for changes for checkout-api over the last quarter?"
• "Build a delivery metrics report with deploy frequency, cycle time p85, WIP and throughput from our PR data"
• "How are we doing on the four keys? Here's the export from Argo CD and PagerDuty"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Write the postmortem for Tuesday's checkout outage from this incident timeline"
• "Define SLOs and burn-rate alerts for the payments service"
• "What product metrics should we track to know if the new onboarding flow worked?"

If another skill answers instead, ask for this one by name: "use delivery-metrics-report".

Check what you get

A good result:

• Every number comes from the script's output. Nothing is typed, rounded "for readability" into a different value, or estimated to fill a gap.
• Metric names and definitions are stated. The report says it uses DORA's current names and how each one is measured, including where recovery time starts.
• One service per report. A mixed-service file is split with --service or the report says it is aggregated and why that weakens it.
• Distributions, not averages. Lead time, recovery time and cycle time are p50 and p85 (p95 where n allows). A mean of durations is never reported.
• Gaps are named. Skipped rows, unresolved incidents, assumed timezones and uncomputed metrics appear in the report.
• Findings cite a week and a count, and name a next check. "Fail rate is high" with no week and no next step fails.
• No team ranking or performance verdict on individuals. Requests for one are declined with the reason.

See a worked example

• checkout api 8 weeks

Use something else when

• Writing up one incident: timeline, impact, contributing factors. Use postmortem-generator.
• Designing SLOs, alerts or dashboards for a service. Use observability-plan.
• Product or business outcome metrics (activation, retention, revenue). Use success-metrics.
• Reporting how people use AI tools. Use ai-usage-report.
• Forecasting infrastructure cost or capacity. Use capacity-cost-model.

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: ai-usage-report, capacity-cost-model, observability-plan, postmortem-generator, success-metrics

Edit this page on GitHub · View source