/dora-check

name: dora-check
description: "Assess delivery health metrics. For software: DORA + APEX. For content/AI/service products: product-type-appropriate metrics."
metadata:
  instruction_budget: "126"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."

Delivery Metrics Check

Assess delivery health using product-type-appropriate metrics. Check `product_type` from `.claude/diamonds/active.yml` to determine which assessment to run.

**Product type routing** (v0.11.0):

• **software**: Full DORA + APEX assessment (Parts 1-3 below)
• **content_course, content_publication, content_media**: Content Delivery Assessment (Part 4 below)
• **ai_tool**: AI Tool Assessment (Part 5 below) + DORA/APEX if code components exist
• **service_offering**: Service Delivery Assessment (Part 6 below)

---

Preflight: Read target canvas file(s) before any Write/Edit

**Hard rule.** Before issuing `Write` or `Edit` against any `.claude/canvas/*.yml`, use the **Read tool** on that file in this session. Claude Code's Read-before-Write check requires the `Read` tool specifically — `cat`/`head`/`grep` via Bash do NOT satisfy it.

**Edit vs Write — different cost profiles** (verified 2026-05-14):

• **`Edit`** (exact-string replacement): `Read` with `limit: 1` satisfies the check at ~50 tokens. State-tracking is per-file, not per-byte — subsequent `Edit` calls work anywhere in the file. Use this for partial updates against large canvas files (e.g., `purpose.yml` at 800+ lines).
• **`Write`** (full replacement): do a **full Read** first. Write obliterates the file; you should see what you're about to replace. The `limit:1` shortcut is *not* appropriate here.

**ID-bearing entries — scan the ID space before assigning** (added 2026-05-15, v0.23.19): When adding a new component, opportunity, solution, or any other ID-bearing entry to a canvas file, run a Bash grep first to confirm the next ID in your prefix sequence is actually free:

grep -o "<prefix>-[0-9][0-9]*" .claude/canvas/<file>.yml | sort -u -t- -k2 -n | tail -3

Replace `<prefix>` with the canvas's ID prefix (`comp` for landscape, `opp` for opportunities, `sol` for solutions, `ht` for human-tasks, etc.). Then pick the next free integer, **matching the zero-padding already used in that file**. The sort is NUMERIC (`-t- -k2 -n`) rather than lexical, and that is not pedantry: a plain `sort -u` orders `ht-1` after `ht-080`, so on a canvas with inconsistent padding it reports the wrong maximum and the next ID collides. Verified on the dogfood repo 2026-08-13, where lexical sort returned `ht-1` as the highest human-task ID against an actual `ht-080`. `grep -o` is also deliberate: it matches IDs wherever they appear, including cross-references and prose, so an ID that was promised somewhere but not yet defined is not handed out twice. `validate_canvas.py` has a duplicate-ID check (lines 230-239) that catches the failure on CI, but a duplicate can persist in the working tree for days if CI isn't run between edit and discovery — see roadmap-repo `corrections.md` 2026-05-15 "Duplicate canvas ID created in landscape.yml" for the worked example.

Original failure mode: anti-pattern #7 instance #5, 2026-05-09 — agent conflated Bash `head` with the Read tool, lost ~14k tokens to a Write-fail → remedial-full-Read → re-Write loop. The `limit:1` discipline (graduated 2026-05-14, v0.23.18) prevents the second-order cost where the agent *correctly* follows the rule but full-Reads every time. The ID-scan discipline (graduated 2026-05-15, v0.23.19) prevents the related class where the agent reads enough of the file to satisfy the Edit check but not enough to see existing ID assignments — kin to anti-pattern #8 (Stale State Read).

If this skill writes to multiple canvas files, register each one first (limit:1 for Edit-only paths; full Read for Write paths) AND ID-scan any prefix you intend to assign.

See `CLAUDE.md` *Canvas writes — Read before Write* for the canonical rule.

Software Products

Assess delivery health using the four core DORA delivery metrics (Forsgren) plus reliability as an operational adjunct, AND LinearB's APEX AI-era metrics.

Part 1: DORA Metrics (Forsgren)

Gather current metrics from CI/CD, deployment logs, incident records.

*Note: DORA's core set is **four delivery metrics** (below). "MTTR" was renamed to "Failed Deployment Recovery Time" (FDRT) for precision — the original was ambiguous with other mean-time-to-X metrics. **Reliability** is an **operational-performance** dimension DORA added in **2021** — dora.dev classifies it as operational, not software-delivery — so it is assessed here as an adjunct via SLOs/SLIs (Part 3 SRE), not as a fifth delivery metric. (The 2024 State of DevOps report's additional delivery metric was **deployment rework rate**, which this skill does not separately track.)*

**Deployment Frequency**: How often does code reach production?

• Elite: On-demand (multiple deploys/day)
• High: Between once/day and once/week
• Medium: Between once/week and once/month
• Low: Less than once/month

**Lead Time for Changes**: Commit to production time?

• Elite: Less than one hour
• High: Between one day and one week
• Medium: Between one week and one month
• Low: More than one month

**Change Failure Rate**: % of deployments causing failure?

• Elite: 0-15%
• High: 16-30%
• Medium: 31-45%
• Low: 46-100%

**Failed Deployment Recovery Time (FDRT)**: Time to restore service after a failed deployment?

• Elite: Less than one hour
• High: Less than one day
• Medium: Between one day and one week
• Low: More than one week

*Formerly "Mean Time to Recovery (MTTR)." Renamed for precision — FDRT measures recovery from failed deployments specifically, not all incidents.*

**Reliabi