{"id":"ef6aecb9-de3c-46e8-9c57-7d13fb0b2a9d","entityType":"agent","slug":"clawhub-athola-nm-minister-dora-metrics","name":"dora-metrics","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-minister-dora-metrics","canonicalPath":"/agent/clawhub-athola-nm-minister-dora-metrics","generatedAt":"2026-10-11T21:00:33.678Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T17:36:15.979Z","emptyReason":null},"description":"Computes DORA delivery-performance metrics from git and GitHub API Skill: dora-metrics Owner: athola Summary: Computes DORA delivery-performance metrics from git and GitHub API Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:17:24.564Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:37:47.638Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:54:31.159Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:03:05.433Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:21:16.094Z | user","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-minister-dora-metrics","sourceUrl":"https://clawhub.ai/athola/nm-minister-dora-metrics","homepage":"https://clawhub.ai/athola/skills/nm-minister-dora-metrics","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-minister-dora-metrics","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-minister-dora-metrics","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Computes DORA delivery-performance metrics from git and GitHub API Skill: dora-metrics Owner: athola Summary: Computes DORA delivery-performance metrics from gi"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:36:15.979Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:36:15.979Z","emptyReason":null},"stars":null,"forks":null,"downloads":1017,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:36:15.965Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T17:36:15.979Z","lastCrawledAt":"2026-10-11T17:36:15.965Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T17:36:15.965Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:17:24.564Z","changelog":"Release v1.9.19","fileCount":5,"zipByteSize":6222},{"version":"1.9.17","createdAt":"2026-07-30T05:37:47.638Z","changelog":"Release v1.9.17","fileCount":5,"zipByteSize":6160},{"version":"1.9.16","createdAt":"2026-07-14T19:54:31.159Z","changelog":"Release v1.9.16","fileCount":5,"zipByteSize":6125},{"version":"1.9.14","createdAt":"2026-06-30T18:03:05.433Z","changelog":"Release v1.9.14","fileCount":5,"zipByteSize":6167},{"version":"1.9.13","createdAt":"2026-06-27T16:21:16.094Z","changelog":"Release v1.9.13","fileCount":5,"zipByteSize":6282},{"version":"1.9.12","createdAt":"2026-06-19T03:16:03.927Z","changelog":"Release v1.9.12","fileCount":5,"zipByteSize":6254},{"version":"1.0.0","createdAt":"2026-06-18T14:11:03.109Z","changelog":"- Initial release: delivers DORA metrics computation from git and GitHub API. - Calculates Deployment Frequency, Lead Time, Change Failure Rate, and Time to Restore Service. - Classifies each metric (Elite, High, Medium, Low) and highlights the bottleneck for improvement. - Supports JSON and human-readable output; integrates with external trend visualization. - Includes thorough guidance for usage, verification, and tier thresholds.","fileCount":5,"zipByteSize":6162}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-minister-dora-metrics","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T21:00:33.675Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-minister-dora-metrics/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T17:36:15.979Z","emptyReason":null},"readme":"Skill: dora-metrics\n\nOwner: athola\n\nSummary: Computes DORA delivery-performance metrics from git and GitHub API\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:17:24.564Z | user\n\nRelease v1.9.19\n\nv1.9.17 | 2026-07-30T05:37:47.638Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:54:31.159Z | user\n\nRelease v1.9.16\n\nv1.9.14 | 2026-06-30T18:03:05.433Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:21:16.094Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:16:03.927Z | user\n\nRelease v1.9.12\n\nv1.0.0 | 2026-06-18T14:11:03.109Z | auto\n\n- Initial release: delivers DORA metrics computation from git and GitHub API.\n- Calculates Deployment Frequency, Lead Time, Change Failure Rate, and Time to Restore Service.\n- Classifies each metric (Elite, High, Medium, Low) and highlights the bottleneck for improvement.\n- Supports JSON and human-readable output; integrates with external trend visualization.\n- Includes thorough guidance for usage, verification, and tier thresholds.\n\nArchive index:\n\nArchive v1.9.19: 5 files, 6222 bytes\n\nFiles: modules/agentic-workflow-signals.md (2429b), modules/thresholds.md (1725b), skill-card.md (2417b), SKILL.md (4700b), _meta.json (144b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: dora-metrics\ndescription: Computes DORA delivery-performance metrics from git and GitHub API\nversion: 1.9.8\ntriggers:\n - dora\n - metrics\n - delivery\n - engineering-management\n - github\n - assessing deployment frequency\n - lead time\n - or change failure rate\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/minister\", \"emoji\": \"\\ud83e\\udd9e\"}}\nsource: claude-night-market\nsource_plugin: minister\n---\n\n> **Night Market Skill** — ported from [claude-night-market/minister](https://github.com/athola/claude-night-market/tree/master/plugins/minister). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# DORA Metrics\n\n## Purpose\n\nCompute the four DORA delivery-performance metrics (Deployment\nFrequency, Lead Time for Changes, Change Failure Rate, and Time to\nRestore Service) from local git history and the GitHub API. Classify\neach metric into Elite, High, Medium, or Low using thresholds from\nDORA's State of DevOps research, and surface the single weakest\ndimension as the next improvement target.\n\n## When to Use\n\n- Engineering management retrospectives and quarterly reviews.\n- Auditing whether agentic workflows (AI-assisted PRs, automated\n deploys) improve velocity and stability or quietly regress them.\n- Feeding a tier signal into `minister:release-health-gates`.\n\n## When Not to Use\n\n- Single-team velocity tracking that needs story-point burndowns\n rather than delivery-performance evidence.\n- Repositories without a clear production branch or release cadence;\n DORA assumes one.\n\n## Workflow\n\n1. Run the helper script with the desired window:\n\n ```bash\n python3 -m minister.dora_metrics --window 30 --branch main\n ```\n\n2. Read the output: per-metric value, tier classification, and the\n bottleneck pointer.\n\n3. For agentic-workflow audits, run the same window twice. Once\n filtering to AI-authored PRs (e.g., `--failure-label ai-bug`),\n once across all PRs. Compare the CFR delta. See\n `modules/agentic-workflow-signals.md`.\n\n4. Optionally pipe `--json` into the tracker so trend data persists\n alongside `release-health-gates` snapshots.\n\n5. Optionally render trend charts with kuva when reviewing multiple\n windows or comparing before/after an agentic-workflow change:\n\n ```bash\n # Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal\n ```\n\n kuva reads TSV/CSV from stdin or a file path. Install once:\n `cargo install kuva --features cli`. No project source changes\n required. See [kuva](https://github.com/Psy-Fer/kuva) for the\n full plot-type reference.\n\n## Inputs\n\n| Flag | Default | Meaning |\n|------|---------|---------|\n| `--window` | 30 | Measurement window in days |\n| `--branch` | HEAD | Production branch |\n| `--failure-label` | bug | GitHub label marking prod failures |\n| `--json` | off | Emit JSON instead of human-readable |\n| `--repo-path` | cwd | Repository directory |\n\n## Outputs\n\nA short text report or JSON payload with:\n\n- Per-metric numeric value (e.g., `4.2/day`, `2.1 hours`, `8%`).\n- Per-metric tier (Elite, High, Medium, Low).\n- Overall tier (the weakest of the four).\n- Bottleneck key, identifying which metric to focus improvement on.\n\n## Tier Thresholds\n\nSee `modules/thresholds.md` for the complete table. Brief summary:\n\n| Metric | Elite | High | Medium | Low |\n|--------|-------|------|--------|-----|\n| DF | >= 1/day | >= 1/week | >= 1/month | < 1/month |\n| LT | <= 1 day | <= 1 week | <= 1 month | > 1 month |\n| CFR | <= 15% | <= 30% | <= 45% | > 45% |\n| TRS | < 1 hour | < 1 day | < 1 week | >= 1 week |\n\n## Verification\n\nConfirm a DORA report is real by re-running the script over a\nnarrower window and checking that DF and LT scale predictably. For\nCFR and TRS, sample two or three of the contributing GitHub issues\nand verify the `bug` (or chosen) label is correct on each.\n\n## Testing\n\nUnit tests live in\n`plugins/minister/tests/unit/test_dora_metrics.py`. Each tier\nboundary is exercised at the threshold, so future contributors who\nadjust an inequality (`>` vs `>=`) trigger a failure rather than a\nsilent regression. Add new tests at the threshold when extending\nclassification logic.\n\n## Exit Criteria\n\n- [ ] DORA report generated for the requested window.\n- [ ] All four metrics classified into a tier.\n- [ ] Bottleneck dimension surfaced.\n- [ ] Output is readable in a terminal or as a PR comment.\n\nFile v1.9.19:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-minister-dora-metrics\",\n \"version\": \"1.9.19\",\n \"publishedAt\": 1787750244564\n}\n\nFile v1.9.19:modules/agentic-workflow-signals.md\n\n# Agentic Workflow Signals from DORA\n\nDORA metrics were designed for human-driven engineering teams, but\nthe same four numbers expose specific failure modes in\nAI-assisted pipelines.\n\n## What to Watch\n\n### Change Failure Rate, AI vs human\n\nRun the metric twice with different `--failure-label` values:\n\n```bash\npython3 -m minister.dora_metrics --window 30 --failure-label bug --json > all.json\npython3 -m minister.dora_metrics --window 30 --failure-label ai-bug --json > ai.json\n```\n\nIf AI-authored CFR exceeds human-authored CFR by more than five\npercentage points, treat it as a signal that review is too lenient\non AI output, not that AI is unsafe in general. The right response\nis usually adding a hookify rule or imbue gate at the friction\npoint, not banning AI assistance.\n\n### Lead Time, before vs after agent adoption\n\nCompute lead time for the 30 days before and after enabling an\nagentic workflow. If LT improved but CFR or TRS regressed, the team\nis trading stability for velocity. The bottleneck dimension surfaced\nby the skill points at which trade was made.\n\n### Time to Restore, agent-driven hotfixes\n\nIf TRS got worse after agents started shipping hotfixes, suspect\nincomplete root-cause analysis. The Replit incident is a case study:\nfast restore claims that turn out to be fabricated extend TRS once\nthe truth surfaces.\n\n### Deployment Frequency, ceiling check\n\nAgents can push DF arbitrarily high. Pair DF with CFR; if DF rose\nand CFR rose proportionally, the agent is generating noise rather\nthan signal. A high-DF, high-CFR team produces churn.\n\n## Producing a Comparison Report\n\nCombine two windows side-by-side:\n\n```python\nfrom minister.dora_metrics import compute_metrics\n# ... collect events for each cohort ...\nhuman = compute_metrics(human_deploys, human_failures, window_days=30)\nagent = compute_metrics(agent_deploys, agent_failures, window_days=30)\nprint(\"Human:\", human.tier())\nprint(\"Agent:\", agent.tier())\nprint(\"Human bottleneck:\", human.bottleneck())\nprint(\"Agent bottleneck:\", agent.bottleneck())\n```\n\nIf the bottleneck differs across cohorts, that is the most\nuseful single output: it tells the engineering manager which\nguardrail is missing for which population.\n\n## Anti-Patterns\n\n- Reporting only DF as proof of agent ROI without CFR.\n- Excluding agent-authored failures from the failure label.\n- Comparing against last quarter when agent adoption mid-window\n invalidates the comparison.\n\nFile v1.9.19:modules/thresholds.md\n\n# DORA Tier Thresholds\n\nSource: DORA's State of DevOps research. The thresholds below match\nthe published bands; minor adjustments per release year are common\nbut the band shape is stable.\n\n## Deployment Frequency (DF)\n\nHow often code is deployed to production. Higher is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At least once per day |\n| High | Between once per week and once per day |\n| Medium | Between once per month and once per week |\n| Low | Less often than once per month |\n\n## Lead Time for Changes (LT)\n\nMedian time from commit to production. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one day |\n| High | One day to one week |\n| Medium | One week to one month |\n| Low | More than one month |\n\n## Change Failure Rate (CFR)\n\nPercentage of deployments that cause a production failure. Lower is\nbetter.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At most 15% |\n| High | 16-30% |\n| Medium | 31-45% |\n| Low | More than 45% |\n\n## Time to Restore Service (TRS)\n\nMedian time to recover from a production failure. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one hour |\n| High | Less than one day |\n| Medium | Less than one week |\n| Low | One week or more |\n\n## Boundary Behavior\n\nThe implementation places the boundary value in the better tier:\n\n- DF exactly 1.0/day classifies as Elite, not High.\n- LT exactly 24 hours classifies as Elite, not High.\n- CFR exactly 15% classifies as Elite, not High.\n- TRS exactly 1 hour classifies as High, not Elite (TRS uses strict\n `<` for Elite to keep the \"less than one hour\" wording honest).\n\nBoundary tests in\n`plugins/minister/tests/unit/test_dora_metrics.py` pin these\nchoices.\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nComputes DORA delivery-performance metrics from git and GitHub API.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, engineering managers, and release teams use this skill to generate DORA delivery-performance reports from repository history and GitHub issue or PR signals. It supports retrospectives, quarterly reviews, and audits of whether agentic workflows improve delivery speed without increasing failure or restore-time risk.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate on broad engineering and metrics terms.\n\nMitigation: Use it only when a DORA report or delivery-performance audit is intended, and review proposed commands before running them.\n\nRisk: The workflow reads repository history and GitHub issue or PR labels.\n\nMitigation: Run it only on repositories where that operational data is appropriate to inspect and share.\n\nRisk: Optional charting asks users to install a third-party Cargo package without a pinned version.\n\nMitigation: Pin or review the charting tool before installation, especially in managed or production workstations.\n\n## Reference(s):\n\n- [Agentic Workflow Signals from DORA](modules/agentic-workflow-signals.md)\n- [DORA Tier Thresholds](modules/thresholds.md)\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-minister-dora-metrics)\n- [Project homepage](https://github.com/athola/claude-night-market/tree/master/plugins/minister)\n- [kuva charting reference](https://github.com/Psy-Fer/kuva)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown with inline shell commands, optional JSON payloads, and short text reports]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Reports can include per-metric numeric values, tier classifications, an overall weakest-tier signal, and a bottleneck dimension.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata; artifact frontmatter reports 1.9.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 5 files, 6160 bytes\n\nFiles: modules/agentic-workflow-signals.md (2429b), modules/thresholds.md (1725b), skill-card.md (2387b), SKILL.md (4700b), _meta.json (144b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: dora-metrics\ndescription: Computes DORA delivery-performance metrics from git and GitHub API\nversion: 1.9.8\ntriggers:\n - dora\n - metrics\n - delivery\n - engineering-management\n - github\n - assessing deployment frequency\n - lead time\n - or change failure rate\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/minister\", \"emoji\": \"\\ud83e\\udd9e\"}}\nsource: claude-night-market\nsource_plugin: minister\n---\n\n> **Night Market Skill** — ported from [claude-night-market/minister](https://github.com/athola/claude-night-market/tree/master/plugins/minister). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# DORA Metrics\n\n## Purpose\n\nCompute the four DORA delivery-performance metrics (Deployment\nFrequency, Lead Time for Changes, Change Failure Rate, and Time to\nRestore Service) from local git history and the GitHub API. Classify\neach metric into Elite, High, Medium, or Low using thresholds from\nDORA's State of DevOps research, and surface the single weakest\ndimension as the next improvement target.\n\n## When to Use\n\n- Engineering management retrospectives and quarterly reviews.\n- Auditing whether agentic workflows (AI-assisted PRs, automated\n deploys) improve velocity and stability or quietly regress them.\n- Feeding a tier signal into `minister:release-health-gates`.\n\n## When Not to Use\n\n- Single-team velocity tracking that needs story-point burndowns\n rather than delivery-performance evidence.\n- Repositories without a clear production branch or release cadence;\n DORA assumes one.\n\n## Workflow\n\n1. Run the helper script with the desired window:\n\n ```bash\n python3 -m minister.dora_metrics --window 30 --branch main\n ```\n\n2. Read the output: per-metric value, tier classification, and the\n bottleneck pointer.\n\n3. For agentic-workflow audits, run the same window twice. Once\n filtering to AI-authored PRs (e.g., `--failure-label ai-bug`),\n once across all PRs. Compare the CFR delta. See\n `modules/agentic-workflow-signals.md`.\n\n4. Optionally pipe `--json` into the tracker so trend data persists\n alongside `release-health-gates` snapshots.\n\n5. Optionally render trend charts with kuva when reviewing multiple\n windows or comparing before/after an agentic-workflow change:\n\n ```bash\n # Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal\n ```\n\n kuva reads TSV/CSV from stdin or a file path. Install once:\n `cargo install kuva --features cli`. No project source changes\n required. See [kuva](https://github.com/Psy-Fer/kuva) for the\n full plot-type reference.\n\n## Inputs\n\n| Flag | Default | Meaning |\n|------|---------|---------|\n| `--window` | 30 | Measurement window in days |\n| `--branch` | HEAD | Production branch |\n| `--failure-label` | bug | GitHub label marking prod failures |\n| `--json` | off | Emit JSON instead of human-readable |\n| `--repo-path` | cwd | Repository directory |\n\n## Outputs\n\nA short text report or JSON payload with:\n\n- Per-metric numeric value (e.g., `4.2/day`, `2.1 hours`, `8%`).\n- Per-metric tier (Elite, High, Medium, Low).\n- Overall tier (the weakest of the four).\n- Bottleneck key, identifying which metric to focus improvement on.\n\n## Tier Thresholds\n\nSee `modules/thresholds.md` for the complete table. Brief summary:\n\n| Metric | Elite | High | Medium | Low |\n|--------|-------|------|--------|-----|\n| DF | >= 1/day | >= 1/week | >= 1/month | < 1/month |\n| LT | <= 1 day | <= 1 week | <= 1 month | > 1 month |\n| CFR | <= 15% | <= 30% | <= 45% | > 45% |\n| TRS | < 1 hour | < 1 day | < 1 week | >= 1 week |\n\n## Verification\n\nConfirm a DORA report is real by re-running the script over a\nnarrower window and checking that DF and LT scale predictably. For\nCFR and TRS, sample two or three of the contributing GitHub issues\nand verify the `bug` (or chosen) label is correct on each.\n\n## Testing\n\nUnit tests live in\n`plugins/minister/tests/unit/test_dora_metrics.py`. Each tier\nboundary is exercised at the threshold, so future contributors who\nadjust an inequality (`>` vs `>=`) trigger a failure rather than a\nsilent regression. Add new tests at the threshold when extending\nclassification logic.\n\n## Exit Criteria\n\n- [ ] DORA report generated for the requested window.\n- [ ] All four metrics classified into a tier.\n- [ ] Bottleneck dimension surfaced.\n- [ ] Output is readable in a terminal or as a PR comment.\n\nFile v1.9.17:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-minister-dora-metrics\",\n \"version\": \"1.9.17\",\n \"publishedAt\": 1785389867638\n}\n\nFile v1.9.17:modules/agentic-workflow-signals.md\n\n# Agentic Workflow Signals from DORA\n\nDORA metrics were designed for human-driven engineering teams, but\nthe same four numbers expose specific failure modes in\nAI-assisted pipelines.\n\n## What to Watch\n\n### Change Failure Rate, AI vs human\n\nRun the metric twice with different `--failure-label` values:\n\n```bash\npython3 -m minister.dora_metrics --window 30 --failure-label bug --json > all.json\npython3 -m minister.dora_metrics --window 30 --failure-label ai-bug --json > ai.json\n```\n\nIf AI-authored CFR exceeds human-authored CFR by more than five\npercentage points, treat it as a signal that review is too lenient\non AI output, not that AI is unsafe in general. The right response\nis usually adding a hookify rule or imbue gate at the friction\npoint, not banning AI assistance.\n\n### Lead Time, before vs after agent adoption\n\nCompute lead time for the 30 days before and after enabling an\nagentic workflow. If LT improved but CFR or TRS regressed, the team\nis trading stability for velocity. The bottleneck dimension surfaced\nby the skill points at which trade was made.\n\n### Time to Restore, agent-driven hotfixes\n\nIf TRS got worse after agents started shipping hotfixes, suspect\nincomplete root-cause analysis. The Replit incident is a case study:\nfast restore claims that turn out to be fabricated extend TRS once\nthe truth surfaces.\n\n### Deployment Frequency, ceiling check\n\nAgents can push DF arbitrarily high. Pair DF with CFR; if DF rose\nand CFR rose proportionally, the agent is generating noise rather\nthan signal. A high-DF, high-CFR team produces churn.\n\n## Producing a Comparison Report\n\nCombine two windows side-by-side:\n\n```python\nfrom minister.dora_metrics import compute_metrics\n# ... collect events for each cohort ...\nhuman = compute_metrics(human_deploys, human_failures, window_days=30)\nagent = compute_metrics(agent_deploys, agent_failures, window_days=30)\nprint(\"Human:\", human.tier())\nprint(\"Agent:\", agent.tier())\nprint(\"Human bottleneck:\", human.bottleneck())\nprint(\"Agent bottleneck:\", agent.bottleneck())\n```\n\nIf the bottleneck differs across cohorts, that is the most\nuseful single output: it tells the engineering manager which\nguardrail is missing for which population.\n\n## Anti-Patterns\n\n- Reporting only DF as proof of agent ROI without CFR.\n- Excluding agent-authored failures from the failure label.\n- Comparing against last quarter when agent adoption mid-window\n invalidates the comparison.\n\nFile v1.9.17:modules/thresholds.md\n\n# DORA Tier Thresholds\n\nSource: DORA's State of DevOps research. The thresholds below match\nthe published bands; minor adjustments per release year are common\nbut the band shape is stable.\n\n## Deployment Frequency (DF)\n\nHow often code is deployed to production. Higher is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At least once per day |\n| High | Between once per week and once per day |\n| Medium | Between once per month and once per week |\n| Low | Less often than once per month |\n\n## Lead Time for Changes (LT)\n\nMedian time from commit to production. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one day |\n| High | One day to one week |\n| Medium | One week to one month |\n| Low | More than one month |\n\n## Change Failure Rate (CFR)\n\nPercentage of deployments that cause a production failure. Lower is\nbetter.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At most 15% |\n| High | 16-30% |\n| Medium | 31-45% |\n| Low | More than 45% |\n\n## Time to Restore Service (TRS)\n\nMedian time to recover from a production failure. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one hour |\n| High | Less than one day |\n| Medium | Less than one week |\n| Low | One week or more |\n\n## Boundary Behavior\n\nThe implementation places the boundary value in the better tier:\n\n- DF exactly 1.0/day classifies as Elite, not High.\n- LT exactly 24 hours classifies as Elite, not High.\n- CFR exactly 15% classifies as Elite, not High.\n- TRS exactly 1 hour classifies as High, not Elite (TRS uses strict\n `<` for Elite to keep the \"less than one hour\" wording honest).\n\nBoundary tests in\n`plugins/minister/tests/unit/test_dora_metrics.py` pin these\nchoices.\n\nFile v1.9.17:skill-card.md\n\n## Description:
\nComputes DORA delivery-performance metrics from git and GitHub API.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers, engineering managers, and release leads use this skill to compute DORA delivery-performance metrics from repository history and GitHub delivery data, classify each metric, and identify the weakest improvement dimension.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill reads local repository history and GitHub delivery data for DORA analysis.
\nMitigation: Run it only in the intended repository and review GitHub token scopes before API use.
\nRisk: Optional plugin and kuva charting installs add separate dependencies outside the skill artifact.
\nMitigation: Verify those dependencies independently before installing or using them.
\nRisk: DORA results can be misleading when the production branch, release cadence, or failure labels are incorrect.
\nMitigation: Re-run reports over a narrower window and sample contributing GitHub issues to confirm labels and events.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-minister-dora-metrics)
\n- [claude-night-market minister plugin](https://github.com/athola/claude-night-market/tree/master/plugins/minister)
\n- [DORA tier thresholds](modules/thresholds.md)
\n- [Agentic workflow signals from DORA](modules/agentic-workflow-signals.md)
\n- [kuva charting tool](https://github.com/Psy-Fer/kuva)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, JSON, shell commands, guidance]
\n**Output Format:** [Markdown guidance with inline shell commands and optional JSON report output]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces per-metric values, tier classifications, an overall tier, and a bottleneck key.]
\n\n## Skill Version(s):
\n1.9.17 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.16: 5 files, 6125 bytes\n\nFiles: modules/agentic-workflow-signals.md (2429b), modules/thresholds.md (1725b), skill-card.md (2280b), SKILL.md (4700b), _meta.json (144b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: dora-metrics\ndescription: Computes DORA delivery-performance metrics from git and GitHub API\nversion: 1.9.8\ntriggers:\n - dora\n - metrics\n - delivery\n - engineering-management\n - github\n - assessing deployment frequency\n - lead time\n - or change failure rate\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/minister\", \"emoji\": \"\\ud83e\\udd9e\"}}\nsource: claude-night-market\nsource_plugin: minister\n---\n\n> **Night Market Skill** — ported from [claude-night-market/minister](https://github.com/athola/claude-night-market/tree/master/plugins/minister). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# DORA Metrics\n\n## Purpose\n\nCompute the four DORA delivery-performance metrics (Deployment\nFrequency, Lead Time for Changes, Change Failure Rate, and Time to\nRestore Service) from local git history and the GitHub API. Classify\neach metric into Elite, High, Medium, or Low using thresholds from\nDORA's State of DevOps research, and surface the single weakest\ndimension as the next improvement target.\n\n## When to Use\n\n- Engineering management retrospectives and quarterly reviews.\n- Auditing whether agentic workflows (AI-assisted PRs, automated\n deploys) improve velocity and stability or quietly regress them.\n- Feeding a tier signal into `minister:release-health-gates`.\n\n## When Not to Use\n\n- Single-team velocity tracking that needs story-point burndowns\n rather than delivery-performance evidence.\n- Repositories without a clear production branch or release cadence;\n DORA assumes one.\n\n## Workflow\n\n1. Run the helper script with the desired window:\n\n ```bash\n python3 -m minister.dora_metrics --window 30 --branch main\n ```\n\n2. Read the output: per-metric value, tier classification, and the\n bottleneck pointer.\n\n3. For agentic-workflow audits, run the same window twice. Once\n filtering to AI-authored PRs (e.g., `--failure-label ai-bug`),\n once across all PRs. Compare the CFR delta. See\n `modules/agentic-workflow-signals.md`.\n\n4. Optionally pipe `--json` into the tracker so trend data persists\n alongside `release-health-gates` snapshots.\n\n5. Optionally render trend charts with kuva when reviewing multiple\n windows or comparing before/after an agentic-workflow change:\n\n ```bash\n # Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal\n ```\n\n kuva reads TSV/CSV from stdin or a file path. Install once:\n `cargo install kuva --features cli`. No project source changes\n required. See [kuva](https://github.com/Psy-Fer/kuva) for the\n full plot-type reference.\n\n## Inputs\n\n| Flag | Default | Meaning |\n|------|---------|---------|\n| `--window` | 30 | Measurement window in days |\n| `--branch` | HEAD | Production branch |\n| `--failure-label` | bug | GitHub label marking prod failures |\n| `--json` | off | Emit JSON instead of human-readable |\n| `--repo-path` | cwd | Repository directory |\n\n## Outputs\n\nA short text report or JSON payload with:\n\n- Per-metric numeric value (e.g., `4.2/day`, `2.1 hours`, `8%`).\n- Per-metric tier (Elite, High, Medium, Low).\n- Overall tier (the weakest of the four).\n- Bottleneck key, identifying which metric to focus improvement on.\n\n## Tier Thresholds\n\nSee `modules/thresholds.md` for the complete table. Brief summary:\n\n| Metric | Elite | High | Medium | Low |\n|--------|-------|------|--------|-----|\n| DF | >= 1/day | >= 1/week | >= 1/month | < 1/month |\n| LT | <= 1 day | <= 1 week | <= 1 month | > 1 month |\n| CFR | <= 15% | <= 30% | <= 45% | > 45% |\n| TRS | < 1 hour | < 1 day | < 1 week | >= 1 week |\n\n## Verification\n\nConfirm a DORA report is real by re-running the script over a\nnarrower window and checking that DF and LT scale predictably. For\nCFR and TRS, sample two or three of the contributing GitHub issues\nand verify the `bug` (or chosen) label is correct on each.\n\n## Testing\n\nUnit tests live in\n`plugins/minister/tests/unit/test_dora_metrics.py`. Each tier\nboundary is exercised at the threshold, so future contributors who\nadjust an inequality (`>` vs `>=`) trigger a failure rather than a\nsilent regression. Add new tests at the threshold when extending\nclassification logic.\n\n## Exit Criteria\n\n- [ ] DORA report generated for the requested window.\n- [ ] All four metrics classified into a tier.\n- [ ] Bottleneck dimension surfaced.\n- [ ] Output is readable in a terminal or as a PR comment.\n\nFile v1.9.16:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-minister-dora-metrics\",\n \"version\": \"1.9.16\",\n \"publishedAt\": 1784058871159\n}\n\nFile v1.9.16:modules/agentic-workflow-signals.md\n\n# Agentic Workflow Signals from DORA\n\nDORA metrics were designed for human-driven engineering teams, but\nthe same four numbers expose specific failure modes in\nAI-assisted pipelines.\n\n## What to Watch\n\n### Change Failure Rate, AI vs human\n\nRun the metric twice with different `--failure-label` values:\n\n```bash\npython3 -m minister.dora_metrics --window 30 --failure-label bug --json > all.json\npython3 -m minister.dora_metrics --window 30 --failure-label ai-bug --json > ai.json\n```\n\nIf AI-authored CFR exceeds human-authored CFR by more than five\npercentage points, treat it as a signal that review is too lenient\non AI output, not that AI is unsafe in general. The right response\nis usually adding a hookify rule or imbue gate at the friction\npoint, not banning AI assistance.\n\n### Lead Time, before vs after agent adoption\n\nCompute lead time for the 30 days before and after enabling an\nagentic workflow. If LT improved but CFR or TRS regressed, the team\nis trading stability for velocity. The bottleneck dimension surfaced\nby the skill points at which trade was made.\n\n### Time to Restore, agent-driven hotfixes\n\nIf TRS got worse after agents started shipping hotfixes, suspect\nincomplete root-cause analysis. The Replit incident is a case study:\nfast restore claims that turn out to be fabricated extend TRS once\nthe truth surfaces.\n\n### Deployment Frequency, ceiling check\n\nAgents can push DF arbitrarily high. Pair DF with CFR; if DF rose\nand CFR rose proportionally, the agent is generating noise rather\nthan signal. A high-DF, high-CFR team produces churn.\n\n## Producing a Comparison Report\n\nCombine two windows side-by-side:\n\n```python\nfrom minister.dora_metrics import compute_metrics\n# ... collect events for each cohort ...\nhuman = compute_metrics(human_deploys, human_failures, window_days=30)\nagent = compute_metrics(agent_deploys, agent_failures, window_days=30)\nprint(\"Human:\", human.tier())\nprint(\"Agent:\", agent.tier())\nprint(\"Human bottleneck:\", human.bottleneck())\nprint(\"Agent bottleneck:\", agent.bottleneck())\n```\n\nIf the bottleneck differs across cohorts, that is the most\nuseful single output: it tells the engineering manager which\nguardrail is missing for which population.\n\n## Anti-Patterns\n\n- Reporting only DF as proof of agent ROI without CFR.\n- Excluding agent-authored failures from the failure label.\n- Comparing against last quarter when agent adoption mid-window\n invalidates the comparison.\n\nFile v1.9.16:modules/thresholds.md\n\n# DORA Tier Thresholds\n\nSource: DORA's State of DevOps research. The thresholds below match\nthe published bands; minor adjustments per release year are common\nbut the band shape is stable.\n\n## Deployment Frequency (DF)\n\nHow often code is deployed to production. Higher is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At least once per day |\n| High | Between once per week and once per day |\n| Medium | Between once per month and once per week |\n| Low | Less often than once per month |\n\n## Lead Time for Changes (LT)\n\nMedian time from commit to production. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one day |\n| High | One day to one week |\n| Medium | One week to one month |\n| Low | More than one month |\n\n## Change Failure Rate (CFR)\n\nPercentage of deployments that cause a production failure. Lower is\nbetter.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At most 15% |\n| High | 16-30% |\n| Medium | 31-45% |\n| Low | More than 45% |\n\n## Time to Restore Service (TRS)\n\nMedian time to recover from a production failure. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one hour |\n| High | Less than one day |\n| Medium | Less than one week |\n| Low | One week or more |\n\n## Boundary Behavior\n\nThe implementation places the boundary value in the better tier:\n\n- DF exactly 1.0/day classifies as Elite, not High.\n- LT exactly 24 hours classifies as Elite, not High.\n- CFR exactly 15% classifies as Elite, not High.\n- TRS exactly 1 hour classifies as High, not Elite (TRS uses strict\n `<` for Elite to keep the \"less than one hour\" wording honest).\n\nBoundary tests in\n`plugins/minister/tests/unit/test_dora_metrics.py` pin these\nchoices.\n\nFile v1.9.16:skill-card.md\n\n## Description:
\nComputes DORA delivery-performance metrics from git and the GitHub API.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers, engineering managers, and release reviewers use this skill to compute deployment frequency, lead time, change failure rate, and time to restore service for a repository and identify the weakest delivery-performance dimension.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill reads local git and GitHub data for the repository where it is invoked.
\nMitigation: Confirm the intended repository path, production branch, and GitHub project before running the workflow.
\nRisk: Optional charting tool installation and trend-data persistence may affect the local environment or create retained metric snapshots.
\nMitigation: Approve optional charting installation and any trend-data persistence explicitly before use.
\n\n\n## Reference(s):
\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-minister-dora-metrics)
\n- [Publisher Profile](https://clawhub.ai/user/athola)
\n- [Project Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/minister)
\n- [Agentic Workflow Signals from DORA](modules/agentic-workflow-signals.md)
\n- [DORA Tier Thresholds](modules/thresholds.md)
\n- [kuva](https://github.com/Psy-Fer/kuva)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, json, shell commands, guidance]
\n**Output Format:** [Markdown or JSON report with optional shell commands for metric collection and charting]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Reports per-metric numeric values, tier classifications, an overall tier, and a bottleneck key.]
\n\n## Skill Version(s):
\n1.9.16 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.14: 5 files, 6167 bytes\n\nFiles: modules/agentic-workflow-signals.md (2429b), modules/thresholds.md (1725b), skill-card.md (2364b), SKILL.md (4700b), _meta.json (144b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: dora-metrics\ndescription: Computes DORA delivery-performance metrics from git and GitHub API\nversion: 1.9.8\ntriggers:\n - dora\n - metrics\n - delivery\n - engineering-management\n - github\n - assessing deployment frequency\n - lead time\n - or change failure rate\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/minister\", \"emoji\": \"\\ud83e\\udd9e\"}}\nsource: claude-night-market\nsource_plugin: minister\n---\n\n> **Night Market Skill** — ported from [claude-night-market/minister](https://github.com/athola/claude-night-market/tree/master/plugins/minister). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# DORA Metrics\n\n## Purpose\n\nCompute the four DORA delivery-performance metrics (Deployment\nFrequency, Lead Time for Changes, Change Failure Rate, and Time to\nRestore Service) from local git history and the GitHub API. Classify\neach metric into Elite, High, Medium, or Low using thresholds from\nDORA's State of DevOps research, and surface the single weakest\ndimension as the next improvement target.\n\n## When to Use\n\n- Engineering management retrospectives and quarterly reviews.\n- Auditing whether agentic workflows (AI-assisted PRs, automated\n deploys) improve velocity and stability or quietly regress them.\n- Feeding a tier signal into `minister:release-health-gates`.\n\n## When Not to Use\n\n- Single-team velocity tracking that needs story-point burndowns\n rather than delivery-performance evidence.\n- Repositories without a clear production branch or release cadence;\n DORA assumes one.\n\n## Workflow\n\n1. Run the helper script with the desired window:\n\n ```bash\n python3 -m minister.dora_metrics --window 30 --branch main\n ```\n\n2. Read the output: per-metric value, tier classification, and the\n bottleneck pointer.\n\n3. For agentic-workflow audits, run the same window twice. Once\n filtering to AI-authored PRs (e.g., `--failure-label ai-bug`),\n once across all PRs. Compare the CFR delta. See\n `modules/agentic-workflow-signals.md`.\n\n4. Optionally pipe `--json` into the tracker so trend data persists\n alongside `release-health-gates` snapshots.\n\n5. Optionally render trend charts with kuva when reviewing multiple\n windows or comparing before/after an agentic-workflow change:\n\n ```bash\n # Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal\n ```\n\n kuva reads TSV/CSV from stdin or a file path. Install once:\n `cargo install kuva --features cli`. No project source changes\n required. See [kuva](https://github.com/Psy-Fer/kuva) for the\n full plot-type reference.\n\n## Inputs\n\n| Flag | Default | Meaning |\n|------|---------|---------|\n| `--window` | 30 | Measurement window in days |\n| `--branch` | HEAD | Production branch |\n| `--failure-label` | bug | GitHub label marking prod failures |\n| `--json` | off | Emit JSON instead of human-readable |\n| `--repo-path` | cwd | Repository directory |\n\n## Outputs\n\nA short text report or JSON payload with:\n\n- Per-metric numeric value (e.g., `4.2/day`, `2.1 hours`, `8%`).\n- Per-metric tier (Elite, High, Medium, Low).\n- Overall tier (the weakest of the four).\n- Bottleneck key, identifying which metric to focus improvement on.\n\n## Tier Thresholds\n\nSee `modules/thresholds.md` for the complete table. Brief summary:\n\n| Metric | Elite | High | Medium | Low |\n|--------|-------|------|--------|-----|\n| DF | >= 1/day | >= 1/week | >= 1/month | < 1/month |\n| LT | <= 1 day | <= 1 week | <= 1 month | > 1 month |\n| CFR | <= 15% | <= 30% | <= 45% | > 45% |\n| TRS | < 1 hour | < 1 day | < 1 week | >= 1 week |\n\n## Verification\n\nConfirm a DORA report is real by re-running the script over a\nnarrower window and checking that DF and LT scale predictably. For\nCFR and TRS, sample two or three of the contributing GitHub issues\nand verify the `bug` (or chosen) label is correct on each.\n\n## Testing\n\nUnit tests live in\n`plugins/minister/tests/unit/test_dora_metrics.py`. Each tier\nboundary is exercised at the threshold, so future contributors who\nadjust an inequality (`>` vs `>=`) trigger a failure rather than a\nsilent regression. Add new tests at the threshold when extending\nclassification logic.\n\n## Exit Criteria\n\n- [ ] DORA report generated for the requested window.\n- [ ] All four metrics classified into a tier.\n- [ ] Bottleneck dimension surfaced.\n- [ ] Output is readable in a terminal or as a PR comment.\n\nFile v1.9.14:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-minister-dora-metrics\",\n \"version\": \"1.9.14\",\n \"publishedAt\": 1782842585433\n}\n\nFile v1.9.14:modules/agentic-workflow-signals.md\n\n# Agentic Workflow Signals from DORA\n\nDORA metrics were designed for human-driven engineering teams, but\nthe same four numbers expose specific failure modes in\nAI-assisted pipelines.\n\n## What to Watch\n\n### Change Failure Rate, AI vs human\n\nRun the metric twice with different `--failure-label` values:\n\n```bash\npython3 -m minister.dora_metrics --window 30 --failure-label bug --json > all.json\npython3 -m minister.dora_metrics --window 30 --failure-label ai-bug --json > ai.json\n```\n\nIf AI-authored CFR exceeds human-authored CFR by more than five\npercentage points, treat it as a signal that review is too lenient\non AI output, not that AI is unsafe in general. The right response\nis usually adding a hookify rule or imbue gate at the friction\npoint, not banning AI assistance.\n\n### Lead Time, before vs after agent adoption\n\nCompute lead time for the 30 days before and after enabling an\nagentic workflow. If LT improved but CFR or TRS regressed, the team\nis trading stability for velocity. The bottleneck dimension surfaced\nby the skill points at which trade was made.\n\n### Time to Restore, agent-driven hotfixes\n\nIf TRS got worse after agents started shipping hotfixes, suspect\nincomplete root-cause analysis. The Replit incident is a case study:\nfast restore claims that turn out to be fabricated extend TRS once\nthe truth surfaces.\n\n### Deployment Frequency, ceiling check\n\nAgents can push DF arbitrarily high. Pair DF with CFR; if DF rose\nand CFR rose proportionally, the agent is generating noise rather\nthan signal. A high-DF, high-CFR team produces churn.\n\n## Producing a Comparison Report\n\nCombine two windows side-by-side:\n\n```python\nfrom minister.dora_metrics import compute_metrics\n# ... collect events for each cohort ...\nhuman = compute_metrics(human_deploys, human_failures, window_days=30)\nagent = compute_metrics(agent_deploys, agent_failures, window_days=30)\nprint(\"Human:\", human.tier())\nprint(\"Agent:\", agent.tier())\nprint(\"Human bottleneck:\", human.bottleneck())\nprint(\"Agent bottleneck:\", agent.bottleneck())\n```\n\nIf the bottleneck differs across cohorts, that is the most\nuseful single output: it tells the engineering manager which\nguardrail is missing for which population.\n\n## Anti-Patterns\n\n- Reporting only DF as proof of agent ROI without CFR.\n- Excluding agent-authored failures from the failure label.\n- Comparing against last quarter when agent adoption mid-window\n invalidates the comparison.\n\nFile v1.9.14:modules/thresholds.md\n\n# DORA Tier Thresholds\n\nSource: DORA's State of DevOps research. The thresholds below match\nthe published bands; minor adjustments per release year are common\nbut the band shape is stable.\n\n## Deployment Frequency (DF)\n\nHow often code is deployed to production. Higher is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At least once per day |\n| High | Between once per week and once per day |\n| Medium | Between once per month and once per week |\n| Low | Less often than once per month |\n\n## Lead Time for Changes (LT)\n\nMedian time from commit to production. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one day |\n| High | One day to one week |\n| Medium | One week to one month |\n| Low | More than one month |\n\n## Change Failure Rate (CFR)\n\nPercentage of deployments that cause a production failure. Lower is\nbetter.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At most 15% |\n| High | 16-30% |\n| Medium | 31-45% |\n| Low | More than 45% |\n\n## Time to Restore Service (TRS)\n\nMedian time to recover from a production failure. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one hour |\n| High | Less than one day |\n| Medium | Less than one week |\n| Low | One week or more |\n\n## Boundary Behavior\n\nThe implementation places the boundary value in the better tier:\n\n- DF exactly 1.0/day classifies as Elite, not High.\n- LT exactly 24 hours classifies as Elite, not High.\n- CFR exactly 15% classifies as Elite, not High.\n- TRS exactly 1 hour classifies as High, not Elite (TRS uses strict\n `<` for Elite to keep the \"less than one hour\" wording honest).\n\nBoundary tests in\n`plugins/minister/tests/unit/test_dora_metrics.py` pin these\nchoices.\n\nFile v1.9.14:skill-card.md\n\n## Description:
\nComputes DORA delivery-performance metrics from git and GitHub API.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers, engineering managers, and release owners use this skill to compute DORA metrics for a repository, classify delivery performance, and identify the weakest delivery dimension to improve.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Broad trigger words may invoke the skill during general conversations about metrics, GitHub, delivery, or lead time.
\nMitigation: Review and narrow the trigger wording before deployment if unwanted invocation would disrupt normal agent workflows.
\nRisk: DORA reports can be misleading when repositories lack a clear production branch, release cadence, or correctly labeled production failures.
\nMitigation: Confirm the branch, window, and failure labels before using the reported tiers for engineering decisions.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-minister-dora-metrics)
\n- [Publisher profile](https://clawhub.ai/user/athola)
\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/minister)
\n- [kuva plotting reference](https://github.com/Psy-Fer/kuva)
\n- [Agentic Workflow Signals from DORA](modules/agentic-workflow-signals.md)
\n- [DORA Tier Thresholds](modules/thresholds.md)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]
\n**Output Format:** [Markdown guidance with shell commands and optional JSON report descriptions]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May describe short text reports or JSON payloads containing per-metric values, tier classifications, overall tier, and bottleneck key.]
\n\n## Skill Version(s):
\n1.9.14 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.13: 5 files, 6282 bytes\n\nFiles: modules/agentic-workflow-signals.md (2429b), modules/thresholds.md (1725b), skill-card.md (2649b), SKILL.md (4700b), _meta.json (144b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: dora-metrics\ndescription: Computes DORA delivery-performance metrics from git and GitHub API\nversion: 1.9.8\ntriggers:\n - dora\n - metrics\n - delivery\n - engineering-management\n - github\n - assessing deployment frequency\n - lead time\n - or change failure rate\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/minister\", \"emoji\": \"\\ud83e\\udd9e\"}}\nsource: claude-night-market\nsource_plugin: minister\n---\n\n> **Night Market Skill** — ported from [claude-night-market/minister](https://github.com/athola/claude-night-market/tree/master/plugins/minister). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# DORA Metrics\n\n## Purpose\n\nCompute the four DORA delivery-performance metrics (Deployment\nFrequency, Lead Time for Changes, Change Failure Rate, and Time to\nRestore Service) from local git history and the GitHub API. Classify\neach metric into Elite, High, Medium, or Low using thresholds from\nDORA's State of DevOps research, and surface the single weakest\ndimension as the next improvement target.\n\n## When to Use\n\n- Engineering management retrospectives and quarterly reviews.\n- Auditing whether agentic workflows (AI-assisted PRs, automated\n deploys) improve velocity and stability or quietly regress them.\n- Feeding a tier signal into `minister:release-health-gates`.\n\n## When Not to Use\n\n- Single-team velocity tracking that needs story-point burndowns\n rather than delivery-performance evidence.\n- Repositories without a clear production branch or release cadence;\n DORA assumes one.\n\n## Workflow\n\n1. Run the helper script with the desired window:\n\n ```bash\n python3 -m minister.dora_metrics --window 30 --branch main\n ```\n\n2. Read the output: per-metric value, tier classification, and the\n bottleneck pointer.\n\n3. For agentic-workflow audits, run the same window twice. Once\n filtering to AI-authored PRs (e.g., `--failure-label ai-bug`),\n once across all PRs. Compare the CFR delta. See\n `modules/agentic-workflow-signals.md`.\n\n4. Optionally pipe `--json` into the tracker so trend data persists\n alongside `release-health-gates` snapshots.\n\n5. Optionally render trend charts with kuva when reviewing multiple\n windows or comparing before/after an agentic-workflow change:\n\n ```bash\n # Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal\n ```\n\n kuva reads TSV/CSV from stdin or a file path. Install once:\n `cargo install kuva --features cli`. No project source changes\n required. See [kuva](https://github.com/Psy-Fer/kuva) for the\n full plot-type reference.\n\n## Inputs\n\n| Flag | Default | Meaning |\n|------|---------|---------|\n| `--window` | 30 | Measurement window in days |\n| `--branch` | HEAD | Production branch |\n| `--failure-label` | bug | GitHub label marking prod failures |\n| `--json` | off | Emit JSON instead of human-readable |\n| `--repo-path` | cwd | Repository directory |\n\n## Outputs\n\nA short text report or JSON payload with:\n\n- Per-metric numeric value (e.g., `4.2/day`, `2.1 hours`, `8%`).\n- Per-metric tier (Elite, High, Medium, Low).\n- Overall tier (the weakest of the four).\n- Bottleneck key, identifying which metric to focus improvement on.\n\n## Tier Thresholds\n\nSee `modules/thresholds.md` for the complete table. Brief summary:\n\n| Metric | Elite | High | Medium | Low |\n|--------|-------|------|--------|-----|\n| DF | >= 1/day | >= 1/week | >= 1/month | < 1/month |\n| LT | <= 1 day | <= 1 week | <= 1 month | > 1 month |\n| CFR | <= 15% | <= 30% | <= 45% | > 45% |\n| TRS | < 1 hour | < 1 day | < 1 week | >= 1 week |\n\n## Verification\n\nConfirm a DORA report is real by re-running the script over a\nnarrower window and checking that DF and LT scale predictably. For\nCFR and TRS, sample two or three of the contributing GitHub issues\nand verify the `bug` (or chosen) label is correct on each.\n\n## Testing\n\nUnit tests live in\n`plugins/minister/tests/unit/test_dora_metrics.py`. Each tier\nboundary is exercised at the threshold, so future contributors who\nadjust an inequality (`>` vs `>=`) trigger a failure rather than a\nsilent regression. Add new tests at the threshold when extending\nclassification logic.\n\n## Exit Criteria\n\n- [ ] DORA report generated for the requested window.\n- [ ] All four metrics classified into a tier.\n- [ ] Bottleneck dimension surfaced.\n- [ ] Output is readable in a terminal or as a PR comment.\n\nFile v1.9.13:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-minister-dora-metrics\",\n \"version\": \"1.9.13\",\n \"publishedAt\": 1782577276094\n}\n\nFile v1.9.13:modules/agentic-workflow-signals.md\n\n# Agentic Workflow Signals from DORA\n\nDORA metrics were designed for human-driven engineering teams, but\nthe same four numbers expose specific failure modes in\nAI-assisted pipelines.\n\n## What to Watch\n\n### Change Failure Rate, AI vs human\n\nRun the metric twice with different `--failure-label` values:\n\n```bash\npython3 -m minister.dora_metrics --window 30 --failure-label bug --json > all.json\npython3 -m minister.dora_metrics --window 30 --failure-label ai-bug --json > ai.json\n```\n\nIf AI-authored CFR exceeds human-authored CFR by more than five\npercentage points, treat it as a signal that review is too lenient\non AI output, not that AI is unsafe in general. The right response\nis usually adding a hookify rule or imbue gate at the friction\npoint, not banning AI assistance.\n\n### Lead Time, before vs after agent adoption\n\nCompute lead time for the 30 days before and after enabling an\nagentic workflow. If LT improved but CFR or TRS regressed, the team\nis trading stability for velocity. The bottleneck dimension surfaced\nby the skill points at which trade was made.\n\n### Time to Restore, agent-driven hotfixes\n\nIf TRS got worse after agents started shipping hotfixes, suspect\nincomplete root-cause analysis. The Replit incident is a case study:\nfast restore claims that turn out to be fabricated extend TRS once\nthe truth surfaces.\n\n### Deployment Frequency, ceiling check\n\nAgents can push DF arbitrarily high. Pair DF with CFR; if DF rose\nand CFR rose proportionally, the agent is generating noise rather\nthan signal. A high-DF, high-CFR team produces churn.\n\n## Producing a Comparison Report\n\nCombine two windows side-by-side:\n\n```python\nfrom minister.dora_metrics import compute_metrics\n# ... collect events for each cohort ...\nhuman = compute_metrics(human_deploys, human_failures, window_days=30)\nagent = compute_metrics(agent_deploys, agent_failures, window_days=30)\nprint(\"Human:\", human.tier())\nprint(\"Agent:\", agent.tier())\nprint(\"Human bottleneck:\", human.bottleneck())\nprint(\"Agent bottleneck:\", agent.bottleneck())\n```\n\nIf the bottleneck differs across cohorts, that is the most\nuseful single output: it tells the engineering manager which\nguardrail is missing for which population.\n\n## Anti-Patterns\n\n- Reporting only DF as proof of agent ROI without CFR.\n- Excluding agent-authored failures from the failure label.\n- Comparing against last quarter when agent adoption mid-window\n invalidates the comparison.\n\nFile v1.9.13:modules/thresholds.md\n\n# DORA Tier Thresholds\n\nSource: DORA's State of DevOps research. The thresholds below match\nthe published bands; minor adjustments per release year are common\nbut the band shape is stable.\n\n## Deployment Frequency (DF)\n\nHow often code is deployed to production. Higher is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At least once per day |\n| High | Between once per week and once per day |\n| Medium | Between once per month and once per week |\n| Low | Less often than once per month |\n\n## Lead Time for Changes (LT)\n\nMedian time from commit to production. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one day |\n| High | One day to one week |\n| Medium | One week to one month |\n| Low | More than one month |\n\n## Change Failure Rate (CFR)\n\nPercentage of deployments that cause a production failure. Lower is\nbetter.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At most 15% |\n| High | 16-30% |\n| Medium | 31-45% |\n| Low | More than 45% |\n\n## Time to Restore Service (TRS)\n\nMedian time to recover from a production failure. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one hour |\n| High | Less than one day |\n| Medium | Less than one week |\n| Low | One week or more |\n\n## Boundary Behavior\n\nThe implementation places the boundary value in the better tier:\n\n- DF exactly 1.0/day classifies as Elite, not High.\n- LT exactly 24 hours classifies as Elite, not High.\n- CFR exactly 15% classifies as Elite, not High.\n- TRS exactly 1 hour classifies as High, not Elite (TRS uses strict\n `<` for Elite to keep the \"less than one hour\" wording honest).\n\nBoundary tests in\n`plugins/minister/tests/unit/test_dora_metrics.py` pin these\nchoices.\n\nFile v1.9.13:skill-card.md\n\n## Description:
\nComputes DORA delivery-performance metrics from git and GitHub API.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers, engineering managers, and release reviewers use this skill to compute DORA delivery metrics from repository and GitHub data, classify delivery performance, and identify the weakest improvement area.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The workflow analyzes git history and GitHub delivery metadata, which may expose sensitive repository, issue, or pull request information to the local agent workflow.
\nMitigation: Run it only on repositories where that metadata exposure is acceptable, and review local data-handling expectations before use.
\nRisk: Broad trigger terms could activate the skill in contexts where DORA analysis is not intended.
\nMitigation: Narrow or customize triggers when accidental activation would disrupt normal repository work.
\nRisk: DORA classifications depend on repository release cadence, production branch selection, and failure labeling quality.
\nMitigation: Verify the selected branch and failure label, rerun over a narrower window, and sample contributing GitHub issues before using results for management decisions.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-minister-dora-metrics)
\n- [Publisher profile](https://clawhub.ai/user/athola)
\n- [OpenClaw homepage metadata](https://github.com/athola/claude-night-market/tree/master/plugins/minister)
\n- [kuva plotting reference](https://github.com/Psy-Fer/kuva)
\n- [Agentic Workflow Signals from DORA](modules/agentic-workflow-signals.md)
\n- [DORA Tier Thresholds](modules/thresholds.md)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance]
\n**Output Format:** [Markdown guidance with shell commands and optional JSON report descriptions]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces per-metric values, tier classifications, an overall tier, and a bottleneck pointer.]
\n\n## Skill Version(s):
\n1.9.13 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.12: 5 files, 6254 bytes\n\nFiles: modules/agentic-workflow-signals.md (2429b), modules/thresholds.md (1725b), skill-card.md (2561b), SKILL.md (4700b), _meta.json (144b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: dora-metrics\ndescription: Computes DORA delivery-performance metrics from git and GitHub API\nversion: 1.9.8\ntriggers:\n - dora\n - metrics\n - delivery\n - engineering-management\n - github\n - assessing deployment frequency\n - lead time\n - or change failure rate\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/minister\", \"emoji\": \"\\ud83e\\udd9e\"}}\nsource: claude-night-market\nsource_plugin: minister\n---\n\n> **Night Market Skill** — ported from [claude-night-market/minister](https://github.com/athola/claude-night-market/tree/master/plugins/minister). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# DORA Metrics\n\n## Purpose\n\nCompute the four DORA delivery-performance metrics (Deployment\nFrequency, Lead Time for Changes, Change Failure Rate, and Time to\nRestore Service) from local git history and the GitHub API. Classify\neach metric into Elite, High, Medium, or Low using thresholds from\nDORA's State of DevOps research, and surface the single weakest\ndimension as the next improvement target.\n\n## When to Use\n\n- Engineering management retrospectives and quarterly reviews.\n- Auditing whether agentic workflows (AI-assisted PRs, automated\n deploys) improve velocity and stability or quietly regress them.\n- Feeding a tier signal into `minister:release-health-gates`.\n\n## When Not to Use\n\n- Single-team velocity tracking that needs story-point burndowns\n rather than delivery-performance evidence.\n- Repositories without a clear production branch or release cadence;\n DORA assumes one.\n\n## Workflow\n\n1. Run the helper script with the desired window:\n\n ```bash\n python3 -m minister.dora_metrics --window 30 --branch main\n ```\n\n2. Read the output: per-metric value, tier classification, and the\n bottleneck pointer.\n\n3. For agentic-workflow audits, run the same window twice. Once\n filtering to AI-authored PRs (e.g., `--failure-label ai-bug`),\n once across all PRs. Compare the CFR delta. See\n `modules/agentic-workflow-signals.md`.\n\n4. Optionally pipe `--json` into the tracker so trend data persists\n alongside `release-health-gates` snapshots.\n\n5. Optionally render trend charts with kuva when reviewing multiple\n windows or comparing before/after an agentic-workflow change:\n\n ```bash\n # Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal\n ```\n\n kuva reads TSV/CSV from stdin or a file path. Install once:\n `cargo install kuva --features cli`. No project source changes\n required. See [kuva](https://github.com/Psy-Fer/kuva) for the\n full plot-type reference.\n\n## Inputs\n\n| Flag | Default | Meaning |\n|------|---------|---------|\n| `--window` | 30 | Measurement window in days |\n| `--branch` | HEAD | Production branch |\n| `--failure-label` | bug | GitHub label marking prod failures |\n| `--json` | off | Emit JSON instead of human-readable |\n| `--repo-path` | cwd | Repository directory |\n\n## Outputs\n\nA short text report or JSON payload with:\n\n- Per-metric numeric value (e.g., `4.2/day`, `2.1 hours`, `8%`).\n- Per-metric tier (Elite, High, Medium, Low).\n- Overall tier (the weakest of the four).\n- Bottleneck key, identifying which metric to focus improvement on.\n\n## Tier Thresholds\n\nSee `modules/thresholds.md` for the complete table. Brief summary:\n\n| Metric | Elite | High | Medium | Low |\n|--------|-------|------|--------|-----|\n| DF | >= 1/day | >= 1/week | >= 1/month | < 1/month |\n| LT | <= 1 day | <= 1 week | <= 1 month | > 1 month |\n| CFR | <= 15% | <= 30% | <= 45% | > 45% |\n| TRS | < 1 hour | < 1 day | < 1 week | >= 1 week |\n\n## Verification\n\nConfirm a DORA report is real by re-running the script over a\nnarrower window and checking that DF and LT scale predictably. For\nCFR and TRS, sample two or three of the contributing GitHub issues\nand verify the `bug` (or chosen) label is correct on each.\n\n## Testing\n\nUnit tests live in\n`plugins/minister/tests/unit/test_dora_metrics.py`. Each tier\nboundary is exercised at the threshold, so future contributors who\nadjust an inequality (`>` vs `>=`) trigger a failure rather than a\nsilent regression. Add new tests at the threshold when extending\nclassification logic.\n\n## Exit Criteria\n\n- [ ] DORA report generated for the requested window.\n- [ ] All four metrics classified into a tier.\n- [ ] Bottleneck dimension surfaced.\n- [ ] Output is readable in a terminal or as a PR comment.\n\nFile v1.9.12:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-minister-dora-metrics\",\n \"version\": \"1.9.12\",\n \"publishedAt\": 1781838963927\n}\n\nFile v1.9.12:modules/agentic-workflow-signals.md\n\n# Agentic Workflow Signals from DORA\n\nDORA metrics were designed for human-driven engineering teams, but\nthe same four numbers expose specific failure modes in\nAI-assisted pipelines.\n\n## What to Watch\n\n### Change Failure Rate, AI vs human\n\nRun the metric twice with different `--failure-label` values:\n\n```bash\npython3 -m minister.dora_metrics --window 30 --failure-label bug --json > all.json\npython3 -m minister.dora_metrics --window 30 --failure-label ai-bug --json > ai.json\n```\n\nIf AI-authored CFR exceeds human-authored CFR by more than five\npercentage points, treat it as a signal that review is too lenient\non AI output, not that AI is unsafe in general. The right response\nis usually adding a hookify rule or imbue gate at the friction\npoint, not banning AI assistance.\n\n### Lead Time, before vs after agent adoption\n\nCompute lead time for the 30 days before and after enabling an\nagentic workflow. If LT improved but CFR or TRS regressed, the team\nis trading stability for velocity. The bottleneck dimension surfaced\nby the skill points at which trade was made.\n\n### Time to Restore, agent-driven hotfixes\n\nIf TRS got worse after agents started shipping hotfixes, suspect\nincomplete root-cause analysis. The Replit incident is a case study:\nfast restore claims that turn out to be fabricated extend TRS once\nthe truth surfaces.\n\n### Deployment Frequency, ceiling check\n\nAgents can push DF arbitrarily high. Pair DF with CFR; if DF rose\nand CFR rose proportionally, the agent is generating noise rather\nthan signal. A high-DF, high-CFR team produces churn.\n\n## Producing a Comparison Report\n\nCombine two windows side-by-side:\n\n```python\nfrom minister.dora_metrics import compute_metrics\n# ... collect events for each cohort ...\nhuman = compute_metrics(human_deploys, human_failures, window_days=30)\nagent = compute_metrics(agent_deploys, agent_failures, window_days=30)\nprint(\"Human:\", human.tier())\nprint(\"Agent:\", agent.tier())\nprint(\"Human bottleneck:\", human.bottleneck())\nprint(\"Agent bottleneck:\", agent.bottleneck())\n```\n\nIf the bottleneck differs across cohorts, that is the most\nuseful single output: it tells the engineering manager which\nguardrail is missing for which population.\n\n## Anti-Patterns\n\n- Reporting only DF as proof of agent ROI without CFR.\n- Excluding agent-authored failures from the failure label.\n- Comparing against last quarter when agent adoption mid-window\n invalidates the comparison.\n\nFile v1.9.12:modules/thresholds.md\n\n# DORA Tier Thresholds\n\nSource: DORA's State of DevOps research. The thresholds below match\nthe published bands; minor adjustments per release year are common\nbut the band shape is stable.\n\n## Deployment Frequency (DF)\n\nHow often code is deployed to production. Higher is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At least once per day |\n| High | Between once per week and once per day |\n| Medium | Between once per month and once per week |\n| Low | Less often than once per month |\n\n## Lead Time for Changes (LT)\n\nMedian time from commit to production. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one day |\n| High | One day to one week |\n| Medium | One week to one month |\n| Low | More than one month |\n\n## Change Failure Rate (CFR)\n\nPercentage of deployments that cause a production failure. Lower is\nbetter.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At most 15% |\n| High | 16-30% |\n| Medium | 31-45% |\n| Low | More than 45% |\n\n## Time to Restore Service (TRS)\n\nMedian time to recover from a production failure. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one hour |\n| High | Less than one day |\n| Medium | Less than one week |\n| Low | One week or more |\n\n## Boundary Behavior\n\nThe implementation places the boundary value in the better tier:\n\n- DF exactly 1.0/day classifies as Elite, not High.\n- LT exactly 24 hours classifies as Elite, not High.\n- CFR exactly 15% classifies as Elite, not High.\n- TRS exactly 1 hour classifies as High, not Elite (TRS uses strict\n `<` for Elite to keep the \"less than one hour\" wording honest).\n\nBoundary tests in\n`plugins/minister/tests/unit/test_dora_metrics.py` pin these\nchoices.\n\nFile v1.9.12:skill-card.md\n\n## Description:
\nComputes DORA delivery-performance metrics from git history and the GitHub API.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers, engineering managers, and release reviewers use this skill to compute and interpret DORA delivery-performance metrics for a repository. It helps compare deployment frequency, lead time, change failure rate, and time to restore service across normal and agent-assisted workflows.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The broad activation list may cause the skill to be considered during general metrics, delivery, or GitHub-related work.
\nMitigation: Invoke it explicitly for DORA or delivery-metrics analysis and ignore it for unrelated repository tasks.
\nRisk: GitHub and repository analysis can include data outside the intended review scope if credentials or paths are too broad.
\nMitigation: Use repository-scoped access, choose the target branch and repository path deliberately, and limit GitHub permissions to the data needed for the report.
\nRisk: DORA classifications can be misleading when production branches, failure labels, or release cadence are not representative.
\nMitigation: Confirm the production branch and failure labels before using the report for management decisions, and sample contributing issues when validating CFR or TRS.
\n\n\n## Reference(s):
\n- [ClawHub skill listing](https://clawhub.ai/athola/nm-minister-dora-metrics)
\n- [Publisher profile](https://clawhub.ai/user/athola)
\n- [Metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/minister)
\n\n\n## Skill Output:
\n**Output Type(s):** [Guidance, Markdown, Shell commands, JSON]
\n**Output Format:** [Markdown guidance with shell command examples and optional JSON report instructions]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [DORA metric values, tier classifications, overall tier, bottleneck dimension, and optional trend-chart commands.]
\n\n## Skill Version(s):
\n1.9.12 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.0: 5 files, 6162 bytes\n\nFiles: modules/agentic-workflow-signals.md (2429b), modules/thresholds.md (1725b), skill-card.md (2457b), SKILL.md (4700b), _meta.json (143b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: dora-metrics\ndescription: Computes DORA delivery-performance metrics from git and GitHub API\nversion: 1.9.8\ntriggers:\n - dora\n - metrics\n - delivery\n - engineering-management\n - github\n - assessing deployment frequency\n - lead time\n - or change failure rate\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/minister\", \"emoji\": \"\\ud83e\\udd9e\"}}\nsource: claude-night-market\nsource_plugin: minister\n---\n\n> **Night Market Skill** — ported from [claude-night-market/minister](https://github.com/athola/claude-night-market/tree/master/plugins/minister). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# DORA Metrics\n\n## Purpose\n\nCompute the four DORA delivery-performance metrics (Deployment\nFrequency, Lead Time for Changes, Change Failure Rate, and Time to\nRestore Service) from local git history and the GitHub API. Classify\neach metric into Elite, High, Medium, or Low using thresholds from\nDORA's State of DevOps research, and surface the single weakest\ndimension as the next improvement target.\n\n## When to Use\n\n- Engineering management retrospectives and quarterly reviews.\n- Auditing whether agentic workflows (AI-assisted PRs, automated\n deploys) improve velocity and stability or quietly regress them.\n- Feeding a tier signal into `minister:release-health-gates`.\n\n## When Not to Use\n\n- Single-team velocity tracking that needs story-point burndowns\n rather than delivery-performance evidence.\n- Repositories without a clear production branch or release cadence;\n DORA assumes one.\n\n## Workflow\n\n1. Run the helper script with the desired window:\n\n ```bash\n python3 -m minister.dora_metrics --window 30 --branch main\n ```\n\n2. Read the output: per-metric value, tier classification, and the\n bottleneck pointer.\n\n3. For agentic-workflow audits, run the same window twice. Once\n filtering to AI-authored PRs (e.g., `--failure-label ai-bug`),\n once across all PRs. Compare the CFR delta. See\n `modules/agentic-workflow-signals.md`.\n\n4. Optionally pipe `--json` into the tracker so trend data persists\n alongside `release-health-gates` snapshots.\n\n5. Optionally render trend charts with kuva when reviewing multiple\n windows or comparing before/after an agentic-workflow change:\n\n ```bash\n # Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal\n ```\n\n kuva reads TSV/CSV from stdin or a file path. Install once:\n `cargo install kuva --features cli`. No project source changes\n required. See [kuva](https://github.com/Psy-Fer/kuva) for the\n full plot-type reference.\n\n## Inputs\n\n| Flag | Default | Meaning |\n|------|---------|---------|\n| `--window` | 30 | Measurement window in days |\n| `--branch` | HEAD | Production branch |\n| `--failure-label` | bug | GitHub label marking prod failures |\n| `--json` | off | Emit JSON instead of human-readable |\n| `--repo-path` | cwd | Repository directory |\n\n## Outputs\n\nA short text report or JSON payload with:\n\n- Per-metric numeric value (e.g., `4.2/day`, `2.1 hours`, `8%`).\n- Per-metric tier (Elite, High, Medium, Low).\n- Overall tier (the weakest of the four).\n- Bottleneck key, identifying which metric to focus improvement on.\n\n## Tier Thresholds\n\nSee `modules/thresholds.md` for the complete table. Brief summary:\n\n| Metric | Elite | High | Medium | Low |\n|--------|-------|------|--------|-----|\n| DF | >= 1/day | >= 1/week | >= 1/month | < 1/month |\n| LT | <= 1 day | <= 1 week | <= 1 month | > 1 month |\n| CFR | <= 15% | <= 30% | <= 45% | > 45% |\n| TRS | < 1 hour | < 1 day | < 1 week | >= 1 week |\n\n## Verification\n\nConfirm a DORA report is real by re-running the script over a\nnarrower window and checking that DF and LT scale predictably. For\nCFR and TRS, sample two or three of the contributing GitHub issues\nand verify the `bug` (or chosen) label is correct on each.\n\n## Testing\n\nUnit tests live in\n`plugins/minister/tests/unit/test_dora_metrics.py`. Each tier\nboundary is exercised at the threshold, so future contributors who\nadjust an inequality (`>` vs `>=`) trigger a failure rather than a\nsilent regression. Add new tests at the threshold when extending\nclassification logic.\n\n## Exit Criteria\n\n- [ ] DORA report generated for the requested window.\n- [ ] All four metrics classified into a tier.\n- [ ] Bottleneck dimension surfaced.\n- [ ] Output is readable in a terminal or as a PR comment.\n\nFile v1.0.0:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-minister-dora-metrics\",\n \"version\": \"1.0.0\",\n \"publishedAt\": 1781791863109\n}\n\nFile v1.0.0:modules/agentic-workflow-signals.md\n\n# Agentic Workflow Signals from DORA\n\nDORA metrics were designed for human-driven engineering teams, but\nthe same four numbers expose specific failure modes in\nAI-assisted pipelines.\n\n## What to Watch\n\n### Change Failure Rate, AI vs human\n\nRun the metric twice with different `--failure-label` values:\n\n```bash\npython3 -m minister.dora_metrics --window 30 --failure-label bug --json > all.json\npython3 -m minister.dora_metrics --window 30 --failure-label ai-bug --json > ai.json\n```\n\nIf AI-authored CFR exceeds human-authored CFR by more than five\npercentage points, treat it as a signal that review is too lenient\non AI output, not that AI is unsafe in general. The right response\nis usually adding a hookify rule or imbue gate at the friction\npoint, not banning AI assistance.\n\n### Lead Time, before vs after agent adoption\n\nCompute lead time for the 30 days before and after enabling an\nagentic workflow. If LT improved but CFR or TRS regressed, the team\nis trading stability for velocity. The bottleneck dimension surfaced\nby the skill points at which trade was made.\n\n### Time to Restore, agent-driven hotfixes\n\nIf TRS got worse after agents started shipping hotfixes, suspect\nincomplete root-cause analysis. The Replit incident is a case study:\nfast restore claims that turn out to be fabricated extend TRS once\nthe truth surfaces.\n\n### Deployment Frequency, ceiling check\n\nAgents can push DF arbitrarily high. Pair DF with CFR; if DF rose\nand CFR rose proportionally, the agent is generating noise rather\nthan signal. A high-DF, high-CFR team produces churn.\n\n## Producing a Comparison Report\n\nCombine two windows side-by-side:\n\n```python\nfrom minister.dora_metrics import compute_metrics\n# ... collect events for each cohort ...\nhuman = compute_metrics(human_deploys, human_failures, window_days=30)\nagent = compute_metrics(agent_deploys, agent_failures, window_days=30)\nprint(\"Human:\", human.tier())\nprint(\"Agent:\", agent.tier())\nprint(\"Human bottleneck:\", human.bottleneck())\nprint(\"Agent bottleneck:\", agent.bottleneck())\n```\n\nIf the bottleneck differs across cohorts, that is the most\nuseful single output: it tells the engineering manager which\nguardrail is missing for which population.\n\n## Anti-Patterns\n\n- Reporting only DF as proof of agent ROI without CFR.\n- Excluding agent-authored failures from the failure label.\n- Comparing against last quarter when agent adoption mid-window\n invalidates the comparison.\n\nFile v1.0.0:modules/thresholds.md\n\n# DORA Tier Thresholds\n\nSource: DORA's State of DevOps research. The thresholds below match\nthe published bands; minor adjustments per release year are common\nbut the band shape is stable.\n\n## Deployment Frequency (DF)\n\nHow often code is deployed to production. Higher is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At least once per day |\n| High | Between once per week and once per day |\n| Medium | Between once per month and once per week |\n| Low | Less often than once per month |\n\n## Lead Time for Changes (LT)\n\nMedian time from commit to production. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one day |\n| High | One day to one week |\n| Medium | One week to one month |\n| Low | More than one month |\n\n## Change Failure Rate (CFR)\n\nPercentage of deployments that cause a production failure. Lower is\nbetter.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At most 15% |\n| High | 16-30% |\n| Medium | 31-45% |\n| Low | More than 45% |\n\n## Time to Restore Service (TRS)\n\nMedian time to recover from a production failure. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one hour |\n| High | Less than one day |\n| Medium | Less than one week |\n| Low | One week or more |\n\n## Boundary Behavior\n\nThe implementation places the boundary value in the better tier:\n\n- DF exactly 1.0/day classifies as Elite, not High.\n- LT exactly 24 hours classifies as Elite, not High.\n- CFR exactly 15% classifies as Elite, not High.\n- TRS exactly 1 hour classifies as High, not Elite (TRS uses strict\n `<` for Elite to keep the \"less than one hour\" wording honest).\n\nBoundary tests in\n`plugins/minister/tests/unit/test_dora_metrics.py` pin these\nchoices.\n\nFile v1.0.0:skill-card.md\n\n## Description:
\nComputes DORA delivery-performance metrics from git and GitHub API.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers, engineering managers, and release teams use this skill to generate DORA metric reports from repository history and GitHub metadata, classify delivery performance, and identify the weakest improvement dimension.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill may activate broadly on generic terms such as metrics or github.
\nMitigation: Use it when the task is specifically about DORA, delivery performance, or repository release metrics.
\nRisk: Metric commands analyze git history and GitHub issue or pull request metadata.
\nMitigation: Run the referenced commands only in repositories where that history and metadata are appropriate to inspect.
\nRisk: DORA metrics can be misleading for repositories without a clear production branch or release cadence.
\nMitigation: Define the production branch, measurement window, and failure label before relying on the report.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/nm-minister-dora-metrics)
\n- [Publisher profile](https://clawhub.ai/user/athola)
\n- [Metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/minister)
\n- [Agentic workflow signals](modules/agentic-workflow-signals.md)
\n- [DORA tier thresholds](modules/thresholds.md)
\n- [kuva plot reference](https://github.com/Psy-Fer/kuva)
\n\n\n## Skill Output:
\n**Output Type(s):** [Guidance, Shell commands, Markdown, JSON, Analysis]
\n**Output Format:** [Markdown guidance with bash examples and optional JSON report output]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Reports per-metric values, tier classifications, overall weakest tier, and a bottleneck key for the selected measurement window.]
\n\n## Skill Version(s):
\n1.0.0 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
","readmeExcerpt":"Skill: dora-metrics Owner: athola Summary: Computes DORA delivery-performance metrics from git and GitHub API Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:17:24.564Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:37:47.638Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:54:31.159Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:03:05.433Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:21:16.094Z | user","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"python3 -m minister.dora_metrics --window 30 --branch main"},{"language":"bash","snippet":"# Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal"},{"language":"bash","snippet":"python3 -m minister.dora_metrics --window 30 --failure-label bug --json > all.json\npython3 -m minister.dora_metrics --window 30 --failure-label ai-bug --json > ai.json"},{"language":"python","snippet":"from minister.dora_metrics import compute_metrics\n# ... collect events for each cohort ...\nhuman = compute_metrics(human_deploys, human_failures, window_days=30)\nagent = compute_metrics(agent_deploys, agent_failures, window_days=30)\nprint(\"Human:\", human.tier())\nprint(\"Agent:\", agent.tier())\nprint(\"Human bottleneck:\", human.bottleneck())\nprint(\"Agent bottleneck:\", agent.bottleneck())"},{"language":"bash","snippet":"python3 -m minister.dora_metrics --window 30 --branch main"},{"language":"bash","snippet":"# Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: dora-metrics\ndescription: Computes DORA delivery-performance metrics from git and GitHub API\nversion: 1.9.8\ntriggers:\n - dora\n - metrics\n - delivery\n - engineering-management\n - github\n - assessing deployment frequency\n - lead time\n - or change failure rate\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/minister\", \"emoji\": \"\\ud83e\\udd9e\"}}\nsource: claude-night-market\nsource_plugin: minister\n---\n\n> **Night Market Skill** — ported from [claude-night-market/minister](https://github.com/athola/claude-night-market/tree/master/plugins/minister). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# DORA Metrics\n\n## Purpose\n\nCompute the four DORA delivery-performance metrics (Deployment\nFrequency, Lead Time for Changes, Change Failure Rate, and Time to\nRestore Service) from local git history and the GitHub API. Classify\neach metric into Elite, High, Medium, or Low using thresholds from\nDORA's State of DevOps research, and surface the single weakest\ndimension as the next improvement target.\n\n## When to Use\n\n- Engineering management retrospectives and quarterly reviews.\n- Auditing whether agentic workflows (AI-assisted PRs, automated\n deploys) improve velocity and stability or quietly regress them.\n- Feeding a tier signal into `minister:release-health-gates`.\n\n## When Not to Use\n\n- Single-team velocity tracking that needs story-point burndowns\n rather than delivery-performance evidence.\n- Repositories without a clear production branch or release cadence;\n DORA assumes one.\n\n## Workflow\n\n1. Run the helper script with the desired window:\n\n ```bash\n python3 -m minister.dora_metrics --window 30 --branch main\n ```\n\n2. Read the output: per-metric value, tier classification, and the\n bottleneck pointer.\n\n3. For agentic-workflow audits, run the same window twice. Once\n filtering to AI-authored PRs (e.g., `--failure-label ai-bug`),\n once across all PRs. Compare the CFR delta. See\n `modules/agentic-workflow-signals.md`.\n\n4. Optionally pipe `--json` into the tracker so trend data persists\n alongside `release-health-gates` snapshots.\n\n5. Optionally render trend charts with kuva when reviewing multiple\n windows or comparing before/after an agentic-workflow change:\n\n ```bash\n # Collect weekly snapshots into a TSV, then plot all four metrics\n # weekmetricvalue\n kuva line trends.tsv --x week --y value --color-by metric \\\n --title \"DORA trends (30-day windows)\" -o dora-trends.svg\n\n # Quick terminal preview without writing a file\n kuva line trends.tsv --x week --y value --color-by metric --terminal\n ```\n\n kuva reads TSV/CSV from stdin or a file path. Install once:\n `cargo install kuva --features cli`. No project source changes\n required. See [kuva](https://github.com/Psy-Fer/kuva) for the\n full plot-type reference.\n\n## Inputs\n\n| Flag | Default | Meaning |\n|------|---------|---------|\n| `--window` | 30 |"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-minister-dora-metrics\",\n \"version\": \"1.9.19\",\n \"publishedAt\": 1787750244564\n}"},{"path":"modules/agentic-workflow-signals.md","content":"# Agentic Workflow Signals from DORA\n\nDORA metrics were designed for human-driven engineering teams, but\nthe same four numbers expose specific failure modes in\nAI-assisted pipelines.\n\n## What to Watch\n\n### Change Failure Rate, AI vs human\n\nRun the metric twice with different `--failure-label` values:\n\n```bash\npython3 -m minister.dora_metrics --window 30 --failure-label bug --json > all.json\npython3 -m minister.dora_metrics --window 30 --failure-label ai-bug --json > ai.json\n```\n\nIf AI-authored CFR exceeds human-authored CFR by more than five\npercentage points, treat it as a signal that review is too lenient\non AI output, not that AI is unsafe in general. The right response\nis usually adding a hookify rule or imbue gate at the friction\npoint, not banning AI assistance.\n\n### Lead Time, before vs after agent adoption\n\nCompute lead time for the 30 days before and after enabling an\nagentic workflow. If LT improved but CFR or TRS regressed, the team\nis trading stability for velocity. The bottleneck dimension surfaced\nby the skill points at which trade was made.\n\n### Time to Restore, agent-driven hotfixes\n\nIf TRS got worse after agents started shipping hotfixes, suspect\nincomplete root-cause analysis. The Replit incident is a case study:\nfast restore claims that turn out to be fabricated extend TRS once\nthe truth surfaces.\n\n### Deployment Frequency, ceiling check\n\nAgents can push DF arbitrarily high. Pair DF with CFR; if DF rose\nand CFR rose proportionally, the agent is generating noise rather\nthan signal. A high-DF, high-CFR team produces churn.\n\n## Producing a Comparison Report\n\nCombine two windows side-by-side:\n\n```python\nfrom minister.dora_metrics import compute_metrics\n# ... collect events for each cohort ...\nhuman = compute_metrics(human_deploys, human_failures, window_days=30)\nagent = compute_metrics(agent_deploys, agent_failures, window_days=30)\nprint(\"Human:\", human.tier())\nprint(\"Agent:\", agent.tier())\nprint(\"Human bottleneck:\", human.bottleneck())\nprint(\"Agent bottleneck:\", agent.bottleneck())\n```\n\nIf the bottleneck differs across cohorts, that is the most\nuseful single output: it tells the engineering manager which\nguardrail is missing for which population.\n\n## Anti-Patterns\n\n- Reporting only DF as proof of agent ROI without CFR.\n- Excluding agent-authored failures from the failure label.\n- Comparing against last quarter when agent adoption mid-window\n invalidates the comparison."},{"path":"modules/thresholds.md","content":"# DORA Tier Thresholds\n\nSource: DORA's State of DevOps research. The thresholds below match\nthe published bands; minor adjustments per release year are common\nbut the band shape is stable.\n\n## Deployment Frequency (DF)\n\nHow often code is deployed to production. Higher is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At least once per day |\n| High | Between once per week and once per day |\n| Medium | Between once per month and once per week |\n| Low | Less often than once per month |\n\n## Lead Time for Changes (LT)\n\nMedian time from commit to production. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one day |\n| High | One day to one week |\n| Medium | One week to one month |\n| Low | More than one month |\n\n## Change Failure Rate (CFR)\n\nPercentage of deployments that cause a production failure. Lower is\nbetter.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | At most 15% |\n| High | 16-30% |\n| Medium | 31-45% |\n| Low | More than 45% |\n\n## Time to Restore Service (TRS)\n\nMedian time to recover from a production failure. Lower is better.\n\n| Tier | Threshold |\n|------|-----------|\n| Elite | Less than one hour |\n| High | Less than one day |\n| Medium | Less than one week |\n| Low | One week or more |\n\n## Boundary Behavior\n\nThe implementation places the boundary value in the better tier:\n\n- DF exactly 1.0/day classifies as Elite, not High.\n- LT exactly 24 hours classifies as Elite, not High.\n- CFR exactly 15% classifies as Elite, not High.\n- TRS exactly 1 hour classifies as High, not Elite (TRS uses strict\n `<` for Elite to keep the \"less than one hour\" wording honest).\n\nBoundary tests in\n`plugins/minister/tests/unit/test_dora_metrics.py` pin these\nchoices."},{"path":"skill-card.md","content":"## Description:\n\nComputes DORA delivery-performance metrics from git and GitHub API.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, engineering managers, and release teams use this skill to generate DORA delivery-performance reports from repository history and GitHub issue or PR signals. It supports retrospectives, quarterly reviews, and audits of whether agentic workflows improve delivery speed without increasing failure or restore-time risk.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate on broad engineering and metrics terms.\n\nMitigation: Use it only when a DORA report or delivery-performance audit is intended, and review proposed commands before running them.\n\nRisk: The workflow reads repository history and GitHub issue or PR labels.\n\nMitigation: Run it only on repositories where that operational data is appropriate to inspect and share.\n\nRisk: Optional charting asks users to install a third-party Cargo package without a pinned version.\n\nMitigation: Pin or review the charting tool before installation, especially in managed or production workstations.\n\n## Reference(s):\n\n- [Agentic Workflow Signals from DORA](modules/agentic-workflow-signals.md)\n- [DORA Tier Thresholds](modules/thresholds.md)\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-minister-dora-metrics)\n- [Project homepage](https://github.com/athola/claude-night-market/tree/master/plugins/minister)\n- [kuva charting reference](https://github.com/Psy-Fer/kuva)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown with inline shell commands, optional JSON payloads, and short text reports]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Reports can include per-metric numeric values, tier classifications, an overall weakest-tier signal, and a bottleneck dimension.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata; artifact frontmatter reports 1.9.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Computes DORA delivery-performance metrics from git and GitHub API Skill: dora-metrics Owner: athola Summary: Computes DORA delivery-performance metrics from git and GitHub API Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:17:24.564Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:37:47.638Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:54:31.159Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:03:05.433Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:21:16.094Z | user","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1639,"uniquenessScore":47,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T17:36:15.979Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T17:36:15.979Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T21:00:33.678Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}