Purpose
Turn noisy engineering platform data into a clear diagnosis of team health — benchmarking against DORA performance tiers, isolating the one or two metrics actually constraining delivery, and producing a ranked intervention plan. Solves the problem of dashboards that show everything and explain nothing.
When to Use
Invoke this skill when the user asks to:
- Analyze DORA metrics or interpret deployment frequency, lead time, change failure rate, and MTTR
- Diagnose why a team's delivery has slowed or become unpredictable
- Break down cycle time to find where work stalls (coding, review, deploy)
- Prepare an engineering health review for leadership or a quarterly business review
- Distinguish which metrics are worth acting on versus normal fluctuation
- Set improvement targets for an engineering team based on current baseline
Inputs Required
Before starting, collect:
- DORA metrics: Current deployment frequency, lead time for changes, change failure rate, MTTR (provide whatever is available)
- Cycle time data: Time-in-stage if available — coding, PR open, review, merge-to-deploy
- Team context: Team size, product maturity (early-stage / scaling / mature), on-call setup
- Time period: The window the data covers, plus prior period for comparison if available
- Recent changes: Reorgs, tooling migrations, freezes, incidents that could distort the data
- Goal: What decision this analysis supports — a target, a bottleneck hunt, or a leadership report
- Data source: Where metrics come from (e.g., GitHub, Jira, CI/CD, an SPACE/DORA tool)
If a metric is missing, analyze what's available and flag the gap rather than fabricating values.
Instructions
Step 1: Benchmark Against DORA Performance Tiers
Classify each of the four DORA metrics into a performance tier:
- Deployment Frequency — Elite: on-demand (multiple/day); High: daily–weekly; Medium: weekly–monthly; Low: less than monthly
- Lead Time for Changes — Elite: under 1 day; High: 1 day–1 week; Medium: 1 week–1 month; Low: over 1 month
- Change Failure Rate — Elite: 0–15%; High: 16–30%; Medium: 16–30%; Low: over 30%
- MTTR — Elite: under 1 hour; High: under 1 day; Medium: 1 day–1 week; Low: over 1 week
State the team's overall tier as the profile that best fits the pattern across all four — not an average. Note any single metric dragging the profile down.
Step 2: Separate Leading from Lagging Indicators
Classify every metric so the user knows which ones predict future outcomes versus which report past ones:
- Leading indicators (predict, actionable now): PR size, review latency, WIP count, time-in-review, batch size, flaky test rate. These move before outcomes change.
- Lagging indicators (report results): deployment frequency, lead time, change failure rate, MTTR. These confirm whether upstream changes worked.
Explicitly warn: optimizing a lagging indicator directly (e.g., "deploy more often") without addressing the leading indicator that constrains it produces gaming, not improvement.
Step 3: Decompose Cycle Time to Locate the Bottleneck
Break lead time into its constituent stages and find where work actually stalls:
- Coding time: first commit → PR opened
- Pickup time: PR opened → first review (the most common silent bottleneck)
- Review time: first review → approval
- Deploy time: merge → production
Identify the single stage consuming the largest disproportionate share. Long pickup time signals review-culture or capacity issues; long deploy time signals pipeline or release-process issues; long coding time signals PR size or scope-creep issues.
Step 4: Filter Signal from Noise
Before drawing conclusions, discount distortions:
- Small-sample volatility: Teams under ~6 engineers or under ~20 deploys/period produce metrics that swing on one incident. Treat single-period spikes with caution.
- Known events: A migration, freeze, or major incident named in inputs explains anomalies — don't diagnose them as trends.
- Trend over point-in-time: A metric is a signal only if it moved consistently across 2+ periods. Flag one-off changes as "watch," not "act."
- Composition shifts: New team members, a large refactor PR, or a holiday period can distort averages — call these out where relevant.
State which findings are high-confidence signals and which are noise or need more data.
Step 5: Diagnose the Constraint
Name the one or two metrics that are the actual constraint on this team's delivery — the bottleneck whose improvement would unlock the most. Connect it back to a leading indicator and a cycle-time stage. Avoid diagnosing all four DORA metrics as "needs improvement"; a real diagnosis prioritizes.
Step 6: Deliver 8 Ranked Interventions
Rank interventions by expected impact on the diagnosed constraint. For each: the action, the leading indicator it moves, and the expected effect on the lagging metric. Order by impact, not category. Examples of the shape:
- Cap PR size (target under ~400 lines) → reduces review time → shortens lead time
- Add a review SLA and pickup alerts → reduces pickup time → shortens lead time
- Automate deploy pipeline steps still done manually → reduces deploy time → raises deployment frequency
Step 7: Set Targets and a Review Cadence
Propose a realistic target for the constrained metric (one tier up, not "elite by next quarter"), the leading indicator to track weekly as the early signal, and a monthly cadence to re-benchmark the four DORA metrics.
Output Format
- Structure: DORA tier scorecard (table) → leading vs. lagging classification → cycle time decomposition → signal/noise assessment → constraint diagnosis → 8 ranked interventions → targets and cadence
- Length: 900–1,300 words
- Format: Structured document with one table for the DORA scorecard; ranked numbered list for interventions; prose for diagnosis
- Sections: DORA Scorecard → Leading vs. Lagging → Cycle Time Breakdown → Signal vs. Noise → Diagnosis → Top 8 Interventions → Targets & Review Cadence
- Tone: Engineering leadership — analytical, decisive, skeptical of vanity metrics; prioritizes rather than lists everything
Quality Checklist
Before delivering output, verify:
- [ ] Each of the four DORA metrics is assigned a specific performance tier with a benchmark cited
- [ ] Every metric discussed is explicitly labeled leading or lagging
- [ ] Cycle time decomposition names the single largest bottleneck stage — not "review takes too long" generally
- [ ] At least one finding is flagged as noise or low-confidence when sample size or known events warrant it
- [ ] The diagnosis names 1–2 constraining metrics — not all four as "needs work"
- [ ] All 8 interventions are ranked by impact, each tied to a leading indicator and a lagging outcome
Notes
- The most common real bottleneck is pickup time (PR waiting for first review), not coding speed — check it early.
- Deployment frequency and lead time move together; if one is off-tier and the other isn't, suspect a data or definition issue.
- Never recommend directly targeting a lagging metric — teams will game it (splitting deploys, gaming failure definitions). Move the leading indicator instead.
- For teams under 6 engineers, treat DORA as directional, not precise; small samples make period-over-period comparison unreliable.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills