[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JJRJRV17R2C8RHFBESSG7J":3,"skill-same:01M6JJRJRV17R2C8RHFBESSG7J":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6JJRJRV17R2C8RHFBESSG7J","cmetrics",null,"Project health and ROI dashboard. Use monthly or when evaluating workflow effectiveness. Shows bugs caught, token cost, and trends.","joshft\u002Fcorrectless","joshft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2847920?v=4","01M6JJGJ1WCYFH1BKGPZJ0Z4YD","josh","01M6JJGJ69XYFA6MTDXSH5BG42",66,"MIT","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcmetrics\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[5,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"edit","bugs","cat","token","project","cost","use","project health","autonomous","workflow","write","read","Bash","health","metrics","artifacts","git","roi","dashboard","2026-11-10 10:12:30",false,"---\nname: cmetrics\ndescription: Project health and ROI dashboard. Use monthly or when evaluating workflow effectiveness. Shows bugs caught, token cost, and trends.\nallowed-tools: Read, Grep, Glob, Bash(git*), Bash(wc*), Bash(find*), Bash(cat*), Bash(jq*), Write(.correctless\u002Fartifacts\u002Fmetrics-*)\ndisallowed-tools: Edit, MultiEdit, NotebookEdit, CreateFile\ninteraction_mode: autonomous\n---\n\n# \u002Fcmetrics — Workflow Metrics Dashboard\n\n> **Shared constraints apply.** Before executing, read `_shared\u002Fconstraints.md` from the parent of this skill's base directory. All constraints there apply to this skill.\n\nAggregate all accumulated workflow data into a project health dashboard. Shows the value the workflow has delivered over time.\n\n## When to Run\n\n- Monthly — to track trends\n- Before presenting to stakeholders — to justify the workflow investment\n- When deciding whether to upgrade from standard to high intensity\n- When something feels off — metrics reveal which phases are pulling weight and which aren't\n\n## Data Sources\n\nRead everything in the accumulation layer. Skip files that don't exist.\n\n### Primary sources:\n1. **QA findings** — `glob .correctless\u002Fartifacts\u002Fqa-findings-*.json` — every QA round from every feature\n2. **Verification reports** — `glob .correctless\u002Fverification\u002F*-verification.md` — every verification\n3. **Workflow effectiveness** — `.correctless\u002Fmeta\u002Fworkflow-effectiveness.json` — post-merge bug history\n4. **Antipatterns** — `.correctless\u002Fantipatterns.md` — accumulated bug classes\n5. **Drift debt** — `.correctless\u002Fmeta\u002Fdrift-debt.json` — architectural erosion\n6. **Olympics findings** — `glob .correctless\u002Fartifacts\u002Ffindings\u002Faudit-*-history.md` — all audit runs\n7. **Specs** — `glob .correctless\u002Fspecs\u002F*.md` — count of features that went through the workflow\n8. **Feature summaries** — `glob .correctless\u002Fartifacts\u002Fsummary-*.md` — per-feature summaries (from \u002Fcsummary)\n9. **Decision records** — `glob .correctless\u002Fdecisions\u002F*.md` — for staleness checks (revisit-when\u002Frevisit-by markers)\n10. **Workflow state files** — `glob .correctless\u002Fartifacts\u002Fworkflow-state-*.json` — for spec_updates counts per feature\n11. **Token logs** — `glob .correctless\u002Fartifacts\u002Ftoken-log-*.jsonl` — per-feature token usage from subagent spawns\n12. **Audit trails** — `glob .correctless\u002Fartifacts\u002Faudit-trail-*.jsonl` — per-branch tool invocation logs from the PostToolUse hook. Contains: timestamp, phase, tool name, file path, branch.\n13. **Git log** — commit history to measure feature velocity and branch durations\n14. **Session meta** — `glob ~\u002F.claude\u002Fusage-data\u002Fsession-meta\u002F*.json` — filter by `project_path` matching the current project root. Contains exact token counts, tool usage, duration, error rates per session.\n15. **Session facets** — `glob ~\u002F.claude\u002Fusage-data\u002Ffacets\u002F*.json` — match by `session_id` to session-meta entries for this project. Contains AI-analyzed session quality: outcome, friction, satisfaction.\n16. **Override history** — `glob .correctless\u002Fmeta\u002Foverrides\u002F*.json` — preserved override logs from completed `\u002Fcauto` runs, for Override Health section\n17. **Deferred findings backlog** — `.correctless\u002Fmeta\u002Fdeferred-findings.json` — centralized backlog of deferred review findings (severity breakdown, oldest open, 30-day trend)\n\n### Derived metrics:\n\n**Features completed** — count of spec files in `.correctless\u002Fspecs\u002F`\n\n**Total issues caught pre-merge** — sum of per-feature gate catches only:\n- Rules added during review (count rules in final spec minus rules in initial draft — approximate by counting total rules per spec)\n- QA findings across all `qa-findings-*.json` files\n- Verification findings from all verification reports\n\nAudit findings are NOT included — any issue found outside the per-feature TDD workflow (review → test audit → QA → verify) is an escape by definition. Audit findings belong in the escape column (see \"Escape Rate\" below).\n\n**Issues by phase** — categorize each issue by which per-feature phase caught it:\n- Spec: rules that reference antipatterns or templates\n- Review: rules added after initial draft (higher-numbered rules in the spec)\n- Test audit: findings from QA rounds labeled as test-quality issues\n- QA: all findings in qa-findings files\n- Verify: findings in verification reports\n\n**Escape rate (three-gate breakdown)** — replaces the single \"Bug escape rate\" line with a three-gate model:\n- **Per-feature escapes**: issues caught by a later per-feature gate. Derived from `qa-findings-*.json` — count of BLOCKING findings across all files. NON-BLOCKING and UNCERTAIN findings are excluded (advisory observations, not escaped defects). Note: QA findings use BLOCKING\u002FNON-BLOCKING\u002FUNCERTAIN severity vocabulary, distinct from audit findings' critical\u002Fhigh\u002Fmedium\u002Flow\u002Finfo vocabulary.\n- **Audit escapes**: issues caught by `\u002Fcaudit` post-feature audits. From round-JSON files in `.correctless\u002Fartifacts\u002Ffindings\u002F`. Count of findings with a non-null `severity` field not equal to `\"info\"` (info findings are not counted as escapes, case-insensitive). Findings without a `severity` field are excluded from escape counts.\n- **Production escapes**: from `workflow-effectiveness.json` `post_merge_bugs` (unchanged source)\n\n**Severity-weighted escape score** — per audit cycle (a set of round-JSON files sharing the same `preset` and `date`). Weights: critical=5, high=3, medium=2, low=1, info=0. Severity matching is case-insensitive — normalize to lowercase before applying the weight mapping. Score = sum of `weight(severity)` across all findings with a valid severity field that is not `\"info\"`.\n\n**Escape breakdown by root cause** — uses the `escape_type` field from round-JSON findings:\n- **Implementation escapes**: code violates spec (`escape_type: \"implementation\"`)\n- **Spec escapes**: spec was too permissive (`escape_type: \"spec\"`)\n- **Unclassified**: no `escape_type` field or null value\nMissing or null `escape_type` is counted as \"unclassified.\"\n\n**Escape trends** — for each preset, compare the current cycle's weighted escape score to the previous cycle's score:\n- **Improving**: score decreased\n- **Stable**: score change \u003C= 20%\n- **Regressing**: score change > 20%\nWhen fewer than 2 cycles exist for a preset, report \"insufficient data for trend.\"\n\n**Severity distribution** — per audit cycle, report count of CRITICAL, HIGH, MEDIUM, LOW findings as a table. Note the distribution shift from previous cycle when available.\n\n**Dormant escape metrics** — when no round-JSON files exist in `.correctless\u002Fartifacts\u002Ffindings\u002F`, the entire escape metrics section is dormant — no error, no warning, just omitted from output. Follows PAT-019.\n\n**Phase effectiveness** — from `workflow-effectiveness.json`:\n- For each phase: bugs that should have been caught vs bugs actually caught\n- Identify weak phases (low catch rate relative to responsibility)\n\n**Antipattern trends** — from `.correctless\u002Fantipatterns.md`:\n- Total entries\n- Group by category — which categories keep growing?\n- Most frequent (highest `Frequency` field)\n\n**Drift debt health** — from `.correctless\u002Fmeta\u002Fdrift-debt.json`:\n- Open items count\n- Oldest open item age\n- Items resolved vs items accumulating\n\n**Olympics history** — from audit history files:\n- Number of runs by preset (QA, Hacker, Perf)\n- Average rounds to convergence\n- Total findings across all runs\n- Recurring patterns flagged\n\n**Olympics staleness** — for \"days since last Olympics\" per preset, take the\nmaximum of two independent signals (ABS-029 \u002F PRH-005 — single-signal\nstaleness was the original PMB-005 bug):\n- (a) mtime of `.correctless\u002Fartifacts\u002Ffindings\u002Faudit-{preset}-history.md` if the file exists\n- (b) mtime of the most recent file matching `.correctless\u002Fartifacts\u002Ffindings\u002Faudit-{preset}-*-round-*.json` if any match\n\nUse the `max` of (a) and (b) — the later of the two timestamps wins. If\nneither signal exists, report the staleness as `no data` literally (never\nsilently zero or \"infinite\"). The comparison is strictly mtime-based — do\nNOT cross-check the round-JSON's `started_at` content; that's the gate's\njob (cmd_audit_done in workflow-advance.sh), not the consumer's. Layer\nseparation is intentional.\n\nAcknowledged residual risk: ENV-003 says filesystem mtime is unreliable\nafter `git checkout`\u002F`git clone`. The consumer side accepts this — \u002Fcmetrics\nis advisory and fail-open; a stale mtime produces a slightly-wrong staleness\nnumber but does not corrupt workflow state. The gate (cmd_audit_done) is\ncontent-based and immune to the same drift.\n\n**Audit-done overrides** — count `audit-done` overrides separately from\ntotal overrides in the Override Health section. A routine `audit-done`\noverride is the AP-023 recurrence pattern for the ABS-029 gate specifically.\nSurface as a dedicated counter line: `audit-done overrides: {N} across {M} runs`.\n\n**Feature velocity** — from git log:\n- Average branch duration (first commit to merge)\n- Features per month\n\n## Output Format\n\nPrint to conversation AND write to `.correctless\u002Fartifacts\u002Fmetrics-{date}.md`:\n\n```markdown\n# Correctless Metrics — {Project Name}\n# Generated: {date}\n\n## Overview\n- **Features completed:** {N} (from spec count)\n- **Issues caught pre-merge:** {N} (per-feature gates only — review, test audit, QA, verify)\n- **Issues escaped to audit:** {N} (found by \u002Fcaudit after landing on main)\n- **Issues escaped to production:** {N} (PMBs)\n- **Workflow active since:** {date of first spec file}\n\n## Issues by Phase (Pre-Merge Gates)\n| Phase | Issues Caught | % of Total | Notes |\n|-------|--------------|------------|-------|\n| Review | {N} | {%} | {e.g., \"Security checklist added 40% of these\"} |\n| Test Audit | {N} | {%} | |\n| QA | {N} | {%} | {e.g., \"3 class fixes added structural tests\"} |\n| Verify | {N} | {%} | |\n\n## Escape Rate (Three-Gate Breakdown)\n\n| Gate | Count | Source |\n|------|-------|--------|\n| Per-feature escapes | {N} BLOCKING findings | qa-findings-*.json |\n| Audit escapes | {N} findings (excl. info) | round-JSON in artifacts\u002Ffindings\u002F |\n| Production escapes | {N} post-merge bugs | workflow-effectiveness.json |\n\n### Severity-Weighted Escape Score\n\nPer audit cycle (grouped by `preset` + `date` from round-JSON files):\n\n| Cycle | Preset | Date | Weighted Score | Trend |\n|-------|--------|------|----------------|-------|\n| {N} | {preset} | {date} | {score} | {improving\u002Fstable\u002Fregressing} |\n\nWeights: critical=5, high=3, medium=2, low=1, info=0. Case-insensitive.\nTrend: improving (score decreased), stable (change \u003C= 20%), regressing (change > 20%).\nWhen fewer than 2 cycles exist for a preset: \"insufficient data for trend.\"\n\n### Root Cause Breakdown\n\n| Category | Count | % |\n|----------|-------|---|\n| Implementation escapes | {N} | {%} |\n| Spec escapes | {N} | {%} |\n| Unclassified | {N} | {%} |\n\nUses `escape_type` field from round-JSON findings. Missing\u002Fnull = unclassified.\n\n### Severity Distribution\n\nPer audit cycle:\n\n| Severity | Count | Shift from Previous |\n|----------|-------|--------------------|\n| CRITICAL | {N} | {+\u002F-N or \"—\"} |\n| HIGH | {N} | {+\u002F-N or \"—\"} |\n| MEDIUM | {N} | {+\u002F-N or \"—\"} |\n| LOW | {N} | {+\u002F-N or \"—\"} |\n\n### Production Bug Escapes\n{From workflow-effectiveness.json — unchanged}\n| ID | Severity | What | Phase That Missed | Why |\n|----|----------|------|-------------------|-----|\n| PMB-001 | {sev} | {desc} | {phase} | {reason} |\n\n**Weakest phase:** {phase with most misses relative to responsibility}\n**Recommendation:** {what to improve — more templates? higher intensity? more QA rounds?}\n\n## Antipattern Trends\n- **Total entries:** {N}\n- **Top categories:**\n  | Category | Count | Trend |\n  |----------|-------|-------|\n  | {category} | {N} | {growing\u002Fstable\u002Fresolved} |\n\n- **Most frequent:** {AP-xxx} — {description} — seen {N} times\n\n{If any category has 3+ entries: \"Consider whether this is an architectural issue, not just a code pattern.\"}\n\n## Drift Debt\n- **Open items:** {N}\n- **Oldest:** {DRIFT-xxx} — {age} days — {description}\n- **Resolved this period:** {N}\n- **Accumulating faster than resolving:** {yes\u002Fno}\n\n{If oldest > 60 days: \"Flag for \u002Fcdevadv analysis — this is rotting.\"}\n\n## Olympics History\n| Run | Preset | Date | Rounds | Findings | Fixed |\n|-----|--------|------|--------|----------|-------|\n| 1 | QA | {date} | {N} | {N} | {N} |\n| 2 | Hacker | {date} | {N} | {N} | {N} |\n\n**Average convergence:** {N} rounds\n**Recurring patterns:** {patterns that keep appearing across runs}\n\n## Mini-Audit Lens Coverage\n\nRead lens data from two sources: (1) qa-findings JSON files (`.correctless\u002Fartifacts\u002Fqa-findings-*.json`) for LENS fields on MA- findings, and (2) lens recommendation artifacts (`.correctless\u002Fartifacts\u002Flens-recommendations-*.json`) for recommended vs. actually-ran data. The LENS field is an open enum — handle unknown lens values gracefully (do not error on unrecognized lens names from recommended lenses).\n\n**Dormant (PAT-019)**: When no lens recommendation artifacts exist under `.correctless\u002Fartifacts\u002F`, the Mini-Audit Lens Coverage section is dormant — omitted from output entirely, no error, no warning. Only display this section when at least one `lens-recommendations-*.json` file exists.\n\nWhen data exists, report:\n\n**(a) Lenses ran across recent features** — from qa-findings JSON LENS fields. Count how many times each lens value appeared across features.\n\n**(b) Recommended lenses vs actually ran** — from lens recommendation artifacts. For each feature with a recommendation artifact, show which recommended lenses were suggested and which actually ran (from the `outcomes` field).\n\n**(c) Finding yield per lens** — findings count divided by times the lens ran. Lenses with zero yield across 3+ features may be stale.\n\n**(d) Promotion candidates** — lenses recommended 3+ times across features are flagged as candidates for promotion to the core lens set or for a new PAT-xxx entry in `.correctless\u002FARCHITECTURE.md`.\n\n## Velocity\n- **Average feature duration:** {N} days (branch creation to merge)\n- **Features per month:** {N}\n- **Workflow overhead per feature:** ~{N} min estimated\n\n## Override Health\n\nRead all files in `.correctless\u002Fmeta\u002Foverrides\u002F*.json`. Compute:\n\n**(a) Total overrides** across all preserved runs — sum `override_count` from each file.\n\n**(b) Mean overrides per run** — total overrides \u002F count of preserved files.\n\n**(c) Override reason frequency** — group overrides by reason using Jaccard similarity (threshold 0.3, invoked via `Bash(source scripts\u002Foverride-scrutiny.sh && jaccard_similarity \"reason_a\" \"reason_b\")`) to cluster similar reasons. Show up to 3 clusters sorted by count descending; ties broken alphabetically by shortest reason in the cluster.\n\nThe clustering threshold (0.3) is intentionally lower than the retry-prevention threshold (0.4 in PRH-006) — clustering for reporting should be loose to surface patterns, while retry prevention should be conservative to avoid blocking legitimate overrides.\n\nIf mean overrides per run > 0.5, emit a warning: \"Override rate is elevated ({mean}\u002Frun). Check the top reasons — this may indicate a gate misclassification (AP-023).\"\n\nIf `.correctless\u002Fmeta\u002Foverrides\u002F` doesn't exist or is empty, the section says: \"No override data yet. Override tracking starts automatically on the next `\u002Fcauto` run.\"\n\n## Deferred Findings Backlog Trend\n\nRead `.correctless\u002Fmeta\u002Fdeferred-findings.json`. If the file does not exist, show: \"No deferred findings data.\"\n\nWhen the file exists, display:\n\n- **Total open count**: findings where `status` is `open`\n- **Severity breakdown**: count of MEDIUM, LOW, ADVISORY among open findings\n- **Oldest open finding**: date and feature of the earliest `deferred_at` among open findings\n- **Resolved in last 30 days**: count of findings where `resolved_at` is within the last 30 days (UTC comparison)\n- **Added in last 30 days**: count of findings where `deferred_at` is within the last 30 days\n\nAll date comparisons use ISO-8601 UTC timestamps. The 30-day trend computation is prompt-level (performed by the LLM agent reading the JSON), not a script.\n\n## Fix-Round Loop Activation\n\nRead `fix_rounds_triggered` from each entry in `.correctless\u002Fmeta\u002Fintensity-calibration.json` (ABS-005 consumer — read-only). Filter to entries where `actual_intensity` is `high` or `critical`.\n\nIf `fix_rounds_triggered` is 0 across 3 or more consecutive high+ intensity features, emit a warning: \"Fix-round loop has not fired in {N} consecutive high+ features — severity calibration may be insufficient (AP-028). Consider reviewing QA findings from recent features to check if NON-BLOCKING ratings were appropriate.\"\n\nIf fewer than 3 high+ features exist, omit the warning: \"Insufficient data — fewer than 3 high+ features completed.\"\n\nIf `fix_rounds_triggered` > 0 in recent features, report the activation count: \"Fix-round loop activated in {N}\u002F{M} recent high+ features ({total} fix rounds total).\"\n\n## ROI Estimate\n- **Issues caught pre-merge:** {N} (per-feature gates only)\n- **Issues escaped to audit:** {N} (caught post-merge by \u002Fcaudit)\n- **Estimated fix time if found in production:** {pre-merge caught} × 2 hours avg = {N} hours\n- **Workflow time invested:** {features} × {overhead per feature} = {N} hours\n- **Net time saved:** {production fix time} - {workflow time} = {N} hours\n\n{This is a rough estimate. Production bugs take 2-10x longer to fix than pre-merge bugs due to debugging, hotfixes, rollbacks, and incident response. The 2-hour average is conservative. Audit escapes are excluded from ROI — they were caught post-merge, so the per-feature workflow didn't prevent them.}\n\n## Health Analysis\n- **QA Round Trend:** {e.g., \"Averaging 2.3 rounds — trending down from 3.1 last quarter.\"}\n- **Antipattern Growth:** {e.g., \"Error handling category growing fastest (+4 in 3 months). Consider architectural pattern.\"}\n- **Drift Staleness:** {e.g., \"3 drift items older than 90 days. Schedule \u002Fcdevadv layers analysis.\"}\n- **Olympics Convergence (at high+ intensity):** {e.g., \"Last 5 runs converged in ≤2 rounds — consider rotating presets.\" Omit this bullet at standard intensity.}\n- **Decision Record Staleness:** {e.g., \"2 decisions have expired revisit-by dates.\"}\n- **Spec Revision Rate:** {e.g., \"Specs revised mid-TDD in 60% of features — spec phase may need more brainstorm time.\"}\n- **Cross-Metric Correlations:** {e.g., \"Spec revision rate is high AND antipattern growth is accelerating in error handling — spec phase isn't learning from antipatterns.\"}\n```\n\n## Health Analysis\n\nAfter computing the raw metrics above, analyze them for actionable insights. This is the interpretive layer — raw numbers without analysis are useless.\n\n**QA Round Trends:**\n- Calculate average QA rounds across all features. If trending up across recent features: \"QA is finding more issues — check whether specs are getting less thorough or code quality is degrading.\"\n- If trending down: \"QA rounds are decreasing — the workflow is getting more effective.\"\n- If suspiciously low (every feature passes in 1 round): \"Every feature passes QA in 1 round. Either code quality is exceptional or QA intensity is too low. Consider increasing min_qa_rounds or adding more hostile QA lenses.\"\n\n**Antipattern Growth:**\n- Group antipatterns by category. Flag the fastest-growing: \"Error handling antipatterns are growing fastest (4 new in last 3 months). This may indicate an architectural gap, not just individual bugs.\"\n- If any category has 5+ entries: \"Consider whether '{category}' is a systemic issue that needs an .correctless\u002FARCHITECTURE.md pattern, not just more antipattern entries.\"\n\n**Drift Debt Staleness:**\n- Flag items older than 90 days: \"{N} drift items are older than 90 days. Stale drift becomes invisible — schedule a `\u002Fcdevadv layers` analysis.\"\n- Compare accumulation vs resolution rate: \"Drift is accumulating {N}x faster than it's being resolved.\"\n\n**Olympics Convergence Speed (high+ intensity):**\n- If last 5 runs all converged in ≤2 rounds: \"Olympics are converging suspiciously fast. Possible causes: (1) lenses are stale, (2) codebase is genuinely clean, (3) agent presets need rotation. Try a custom preset.\"\n- If convergence is getting slower: \"Olympics are taking more rounds — new code may be introducing complexity the current lenses don't cover well.\"\n\n**Decision Record Staleness:**\n- Scan `.correctless\u002Fdecisions\u002F` for files with `revisit-when` or `revisit-by` markers. Flag expired conditions.\n\n**Spec Revision Rate:**\n- If specs are frequently revised during TDD (high spec_updates counts across features): \"Specs are being revised mid-TDD frequently. The spec phase may not be thorough enough — consider more Socratic brainstorm time or research steps.\"\n\n**Cross-Metric Correlations (the most valuable insights):**\n- \"Spec revision rate is high AND antipattern growth is accelerating in the same category\" → spec phase isn't learning from antipatterns\n- \"QA rounds are low BUT post-merge bugs are increasing\" → QA is too lenient\n- \"Drift debt is growing AND Olympics convergence is fast\" → drift may be in areas Olympics don't cover\n- \"Review phase catches fewer issues over time BUT antipattern count is growing\" → review isn't reading antipatterns effectively\n\n## Token ROI Analysis\n\nRead all `.correctless\u002Fartifacts\u002Ftoken-log-*.jsonl` files. Correlate token spend with findings data from QA, verification, and audit artifacts.\n\n### Metrics to Compute\n\n**1. Cost per bug caught**: When cost artifacts exist (`.correctless\u002Fartifacts\u002Fcost-*.json`), compute actual USD cost: \"Across {N} features, you spent ${X} and caught {B} bugs — ${X\u002FB} per bug caught pre-merge.\" Falls back to token-count-based estimates when cost artifacts are missing: \"Across {N} features, you spent {T} tokens and caught {B} bugs — {T\u002FB} tokens per bug caught pre-merge.\"\n\n**2. Tokens per feature by phase**: Group all token log entries by the `feature` field and sum `total_tokens` per feature. Show as a table:\n\n| Phase | Tokens | % of Total | Findings | Tokens\u002FFinding |\n|-------|--------|-----------|----------|----------------|\n| TDD (ctdd) | {N} | {%} | {N} | {N} |\n| Review (creview\u002Fcreview-spec) | {N} | {%} | {N} | {N} |\n| Verification (cverify) | {N} | {%} | {N} | {N} |\n| Audit (caudit) | {N} | {%} | {N} | {N} |\n| Other (all remaining: cspec, cdebug, crefactor, cmodel, credteam, cdevadv, cpostmortem) | {N} | {%} | {N} | {N} |\n\nThis shows where the budget goes. If 65% goes to TDD and TDD catches 60% of bugs, the allocation is efficient. If 40% goes to audit and it catches 5% of bugs, consider reducing audit intensity.\n\n**3. Bug escape rate**: From `workflow-effectiveness.json`: `post_merge_bugs` count \u002F (total caught + escaped). \"Escape rate: {N}%. {M} caught pre-merge, {K} escaped.\"\n\n**4. Estimated production fix cost avoided**: Each caught bug saves an estimated 2-10 hours of production debugging, hotfixes, rollbacks, and incident response. \"{N} bugs caught × 2-10 hours = {range} hours saved. At USD 150\u002Fhr developer cost, that's ${range} saved.\" This is a rough estimate — say so. But even the conservative end usually exceeds the token cost.\n\n**5. Tokens per LOC**: Total tokens \u002F total lines added (from git diff --stat across features). Track over time — should be stable if overhead scales linearly.\n\n**6. Olympics efficiency** (high+ intensity): Tokens per finding per round. \"Round 1: {N} findings at {T} tokens. Round {M}: {N} findings at {T} tokens.\" Shows diminishing returns.\n\n**7. Token trend**: Split completed features chronologically into two halves (first N\u002F2 vs second N\u002F2; for odd counts, the middle feature goes to the first half). Compute the average tokens per feature for each half. If the second half average exceeds the first half average by more than 20%, the trend is \"growing\". If the second half average is more than 20% lower than the first half average, the trend is \"shrinking\". Otherwise the trend is \"stable\" (within 20% threshold). If fewer than 4 features have token data, the trend is \"insufficient data\". Report: \"Token cost per feature: {growing\u002Fshrinking\u002Fstable\u002Finsufficient data}. First half average: {N}. Second half average: {N}. Cost per bug: {improving\u002Fdegrading}.\"\n\n**8. Tool call distribution per phase**: From audit trail JSONL files, count tool invocations grouped by phase. Shows where tool activity concentrates — if 80% of Edit calls happen in tdd-impl (GREEN), the implementation phase is the most write-heavy.\n\n### Output\n\nAdd to the dashboard after the existing ROI Estimate section:\n\n```markdown\n## Token ROI Analysis\n\n### Cost Summary\n- **Total tokens tracked:** {N} across {M} features\n- **Average tokens per feature:** {N}\n- **Cost per bug caught:** {N} tokens ({M} bugs caught)\n\n### Phase Distribution\n| Phase | Tokens | % of Total | Findings | Tokens\u002FFinding |\n|-------|--------|-----------|----------|----------------|\n| TDD (ctdd) | {N} | {%} | {N} | {N} |\n| Review (creview, creview-spec) | {N} | {%} | {N} | {N} |\n| Verification (cverify) | {N} | {%} | {N} | {N} |\n| Audit (caudit) | {N} | {%} | {N} | {N} |\n| Other (cspec, cdebug, crefactor, cmodel, credteam, cdevadv, cpostmortem) | {N} | {%} | {N} | {N} |\n\n### Per-Feature Token Cost\n\nRead all `token-log-*.jsonl` files from `.correctless\u002Fartifacts\u002F`. Produce a per-feature token cost table alongside the Phase Distribution table. Each row represents one feature. Extract the feature slug from the JSONL filename (the portion between `token-log-` and `.jsonl`).\n\nColumns: feature slug, total tokens, tokens by skill category (TDD, Review, Verification, Audit, Other), and QA rounds.\n\nUse the JSONL `skill` field for category mapping:\n- ctdd maps to TDD\n- creview\u002Fcreview-spec maps to Review\n- cverify maps to Verification\n- caudit maps to Audit\n- all others map to Other\n\nRead QA rounds from the workflow state file (`.correctless\u002Fartifacts\u002Fworkflow-state-{slug}.json`, field `qa_rounds`) for each feature. If no workflow state file exists for a feature, show \"–\" in the QA Rounds column. If a JSONL entry lacks a `skill` field, infer the category from the `phase` field using the same mapping.\n\nThe table is sorted by total tokens descending. If no token log files exist, skip this section with a note: \"No token log data available.\"\n\n| Feature Slug | Total Tokens | TDD | Review | Verification | Audit | Other | QA Rounds |\n|-------------|-------------|-----|--------|-------------|-------|-------|-----------|\n| {slug} | {N} | {N} | {N} | {N} | {N} | {N} | {N} |\n\n### Bug Escape Rate\n- **Pre-merge bugs caught:** {N}\n- **Post-merge bugs escaped:** {M}\n- **Escape rate:** {%}\n- **Estimated production fix cost avoided:** {N bugs} × 2-10 hours = {range} hours (~${range} at USD 150\u002Fhr)\n\n### Efficiency\n- **Tokens per LOC:** {N} (total tokens \u002F lines added across features)\n- **Olympics efficiency (high+ intensity):** Round 1: {N} findings at {T}k tokens → Round {M}: {N} findings at {T}k tokens\n\n### Token Trend\n- Token cost per feature: {growing\u002Fshrinking\u002Fstable\u002Finsufficient data} (first half average vs second half average, 20% threshold)\n- Cost per bug caught: {improving\u002Fdegrading}\n```\n\nIf no token logs exist, skip this section with: \"No token usage data yet. Token tracking starts automatically when skills run — data will appear after the next feature.\"\n\n## Session Analytics (from Claude Code data)\n\nDetermine the current project root: `git rev-parse --show-toplevel`. Then use `find ~\u002F.claude\u002Fusage-data\u002Fsession-meta\u002F -name '*.json'` to list all session-meta files (do NOT use Glob with `~` — use find or Bash for tilde expansion). Filter to sessions where `project_path` matches the project root (exact string match on the absolute path). For each matching session, look up the corresponding facets file at `~\u002F.claude\u002Fusage-data\u002Ffacets\u002F{session_id}.json` (the facets filename IS the session_id).\n\nNote: Not all sessions have facets files (~26% coverage is typical). When computing facets-based metrics, note the sample size: \"Outcome data available for {N} of {M} sessions ({%}).\"\n\n### Metrics to Compute\n\n**From session-meta:**\n\n- **Exact token cost**: Sum `input_tokens + output_tokens` across all project sessions. This is ground truth — cross-check against manual token logs. If they diverge significantly, note: \"Session-meta shows {N} tokens total. Token logs show {M}. The difference ({D}) is orchestrator overhead not captured by subagent tracking.\"\n- **Average session duration**: `mean(duration_minutes)` across sessions.\n- **Tool distribution**: Aggregate `tool_counts` across sessions. Show top 6 tools by call count.\n- **Friction rate**: `sum(tool_errors) \u002F sum(all tool calls)`. Break down by `tool_error_categories`.\n- **User engagement**: Average `user_response_times`. Long times (>60s) suggest confusion. Short times (\u003C15s) suggest flow.\n\n**From facets:**\n\n- **Outcome rate**: % of sessions with `outcome: \"fully_achieved\"`.\n- **Satisfaction**: Distribution of `claude_helpfulness` values.\n- **Top friction categories**: Aggregate `friction_counts` across sessions. Flag growing categories.\n\n**Correctless vs Freeform comparison:**\n\nIdentify Correctless sessions by checking whether Correctless artifacts were modified during the session's time window. A session is \"Correctless\" if:\n- Workflow state files (`.correctless\u002Fartifacts\u002Fworkflow-state-*.json`) have `phase_entered_at` timestamps within the session's `start_time` to `start_time + duration_minutes` range, OR\n- The session's `tool_counts` includes calls to tools that only Correctless uses (the `Task` tool with high counts suggests orchestrated workflow), OR\n- QA findings, verification reports, or spec files were modified during the session window (check git log timestamps)\n\nIf none of these signals are present, the session is \"freeform.\" Note: this heuristic is approximate — some Correctless sessions (e.g., `\u002Fcstatus` or `\u002Fchelp`) may look freeform. Err on the side of undercounting Correctless sessions rather than overcounting.\n\n**Important:** Slash commands like `\u002Fcspec` are intercepted by Claude Code before reaching the conversation — they do NOT appear in `first_prompt`. Do not use `first_prompt` to identify Correctless sessions.\n\n### Output\n\n```markdown\n## Session Analytics\n\n### Overview\n- **Sessions tracked:** {N} (from {date} to {date})\n- **Average session duration:** {N} minutes\n- **Total tokens (ground truth):** {N} input + {N} output\n\n### Tool Distribution\n| Tool | Calls | % of Total |\n|------|-------|-----------|\n| {tool} | {N} | {%} |\n\n### Quality Signals\n- **Outcome rate:** {N}% fully achieved\n- **Helpfulness:** {distribution}\n- **Friction rate:** {N}% tool errors\n- **Top friction:** {category from facets friction_counts} ({N} occurrences)\n- **User engagement:** avg response time {N}s ({\u003C15s: flowing | 15-60s: normal | >60s: confused})\n\n### Correctless vs Freeform\n| Metric | Correctless Sessions | Freeform Sessions |\n|--------|---------------------|-------------------|\n| Outcome rate | {%} | {%} |\n| Friction rate | {%} | {%} |\n| Avg duration | {N} min | {N} min |\n| Avg tokens | {N} | {N} |\n```\n\nIf no session-meta data exists for this project, skip with: \"No Claude Code session data found for this project. Session analytics will appear after running a few sessions.\"\n\n## Trend Tracking\n\nIf previous metrics files exist (`.correctless\u002Fartifacts\u002Fmetrics-*.md`), compare:\n- Is the bug escape rate improving? (should decrease over time)\n- Are more issues being caught earlier? (review should catch more as templates improve)\n- Is drift debt accumulating or resolving?\n- Are Olympics converging faster? (should, as antipatterns grow)\n\nNote trends: \"Bug escape rate: 5% → 3% → 1.5% over 3 months. The workflow is getting more effective.\"\n\n## Claude Code Feature Integration\n\n### Task Lists\nUse TaskCreate\u002FTaskUpdate:\n- Reading QA findings (N files)\n- Reading verification reports (N files)\n- Reading workflow effectiveness data\n- Reading antipatterns\n- Reading drift debt\n- Reading Olympics history\n- Reading git log\n- Calculating metrics\n- Reading decision records\n- Reading session analytics data\n- Analyzing health indicators\n- Reading token logs and computing ROI\n- Generating dashboard\n\n## Autonomous Defaults\n\n- **AD-001**: Report scope — generate full metrics dashboard (default). No human input required; this skill runs to completion autonomously.\n\n## If Something Goes Wrong\n\n- `\u002Fcmetrics` writes a dashboard artifact but does not modify workflow state or source code. Re-run anytime safely.\n- If metrics are sparse, that's normal for new projects — data accumulates with each feature. Key sources: QA findings from `\u002Fctdd`, verification reports from `\u002Fcverify`, antipatterns from `\u002Fcpostmortem`.\n\n## Constraints\n\n- **Read-only.** This skill aggregates data. It does not modify anything.\n- **Be honest about estimates.** The ROI calculation is rough. Say so. Don't oversell.\n- **Missing data is normal.** A new project will have sparse metrics. Report what exists and note what will accumulate with more features.\n- **Don't compare to other projects.** Each project's metrics only compare to its own history.\n- **The \"issues caught\" number includes deduplication.** If review and QA both caught the same issue, count it once at the earliest phase.\n- **Redact if sharing.** If this output will be shared externally, apply redaction rules from `templates\u002Fredaction-rules.md` first.\n\nFor a full project dashboard, run `\u002Fcdashboard` and open `.correctless\u002Fdashboard\u002Findex.html` in a browser.\n","# \u002Fcmetrics — Workflow Metrics Dashboard\n\n> **Shared constraints apply.** Before executing, read `_shared\u002Fconstraints.md` from the parent of this skill's base directory. All constraints there apply to this skill.\n\nAggregate all accumulated workflow data into a project health dashboard. Shows the value the workflow has delivered over time.\n\n## When to Run\n\n- Monthly — to track trends\n- Before presenting to stakeholders — to justify the workflow investment\n- When deciding whether to upgrade from standard to high intensity\n- When something feels off — metrics reveal which phases are pulling weight and which aren't\n\n## Data Sources\n\nRead everything in the accumulation layer. Skip files that don't exist.\n\n### Primary sources:\n1. **QA findings** — `glob .correctless\u002Fartifacts\u002Fqa-findings-*.json` — every QA round from every feature\n2. **Verification reports** — `glob .correctless\u002Fverification\u002F*-verification.md` — every verification\n3. **Workflow effectiveness** — `.correctless\u002Fmeta\u002Fworkflow-effectiveness.json` — post-merge bug history\n4. **Antipatterns** — `.correctless\u002Fantipatterns.md` — accumulated bug classes\n5. **Drift debt** — `.correctless\u002Fmeta\u002Fdrift-debt.json` — architectural erosion\n6. **Olympics findings** — `glob .correctless\u002Fartifacts\u002Ffindings\u002Faudit-*-history.md` — all audit runs\n7. **Specs** — `glob .correctless\u002Fspecs\u002F*.md` — count of features that went through the workflow\n8. **Feature summaries** — `glob .correctless\u002Fartifacts\u002Fsummary-*.md` — per-feature summaries (from \u002Fcsummary)\n9. **Decision records** — `glob .correctless\u002Fdecisions\u002F*.md` — for staleness checks (revisit-when\u002Frevisit-by markers)\n10. **Workflow state files** — `glob .correctless\u002Fartifacts\u002Fworkflow-state-*.json` — for spec_updates counts per feature\n11. **Token logs** — `glob .correctless\u002Fartifacts\u002Ftoken-log-*.jsonl` — per-feature token usage from subagent spawns\n12. **Audit trails** — `glob .correctless\u002Fartifacts\u002Faudit-trail-*.jsonl` — per-branch tool invocation logs from the PostToolUse hook. Contains: timestamp, phase, tool name, file path, branch.\n13. **Git log** — commit history to measure feature velocity and branch durations\n14. **Session meta** — `glob ~\u002F.claude\u002Fusage-data\u002Fsession-meta\u002F*.json` — filter by `project_path` matching the current project root. Contains exact token counts, tool usage, duration, error rates per session.\n15. **Session facets** — `glob ~\u002F.claude\u002Fusage-data\u002Ffacets\u002F*.json` — match by `session_id` to session-meta entries for this project. Contains AI-analyzed session quality: outcome, friction, satisfaction.\n16. **Override history** — `glob .correctless\u002Fmeta\u002Foverrides\u002F*.json` — preserved override logs from completed `\u002Fcauto` runs, for Override Health section\n17. **Deferred findings backlog** — `.correctless\u002Fmeta\u002Fdeferred-findings.json` — centralized backlog of deferred review findings (severity breakdown, oldest open, 30-day trend)\n\n### Derived metrics:\n\n**Features completed** — count of spec files in `.correctless\u002Fspecs\u002F`\n\n**Total issues caught pre-merge** — sum of per-feature gate catches only:\n- Rules added during review (count rules in final spec minus rules in initial draft — approximate by counting total rules per spec)\n- QA findings across all `qa-findings-*.json` files\n- Verification findings from all verification reports\n\nAudit findings are NOT included — any issue found outside the per-feature TDD workflow (review → test audit → QA → verify) is an escape by definition. Audit findings belong in the escape column (see \"Escape Rate\" below).\n\n**Issues by phase** — categorize each issue by which per-feature phase caught it:\n- Spec: rules that reference antipatterns or templates\n- Review: rules added after initial draft (higher-numbered rules in the spec)\n- Test audit: findings from QA rounds labeled as test-quality issues\n- QA: all findings in qa-findings files\n- Verify: findings in verification reports\n\n**Escape rate (three-gate breakdown)** — replaces the single \"Bug escape rate\" line with a three-gate model:\n- **Per-feature escapes**: issues caught by a later per-feature gate. Derived from `qa-findings-*.json` — count of BLOCKING findings across all files. NON-BLOCKING and UNCERTAIN findings are excluded (advisory observations, not escaped defects). Note: QA findings use BLOCKING\u002FNON-BLOCKING\u002FUNCERTAIN severity vocabulary, distinct from audit findings' critical\u002Fhigh\u002Fmedium\u002Flow\u002Finfo vocabulary.\n- **Audit escapes**: issues caught by `\u002Fcaudit` post-feature audits. From round-JSON files in `.correctless\u002Fartifacts\u002Ffindings\u002F`. Count of findings with a non-null `severity` field not equal to `\"info\"` (info findings are not counted as escapes, case-insensitive). Findings without a `severity` field are excluded from escape counts.\n- **Production escapes**: from `workflow-effectiveness.json` `post_merge_bugs` (unchanged source)\n\n**Severity-weighted escape score** — per audit cycle (a set of round-JSON files sharing the same `preset` and `date`). Weights: critical=5, high=3, medium=2, low=1, info=0. Severity matching is case-insensitive — normalize to lowercase before applying the weight mapping. Score = sum of `weight(severity)` across all findings with a valid severity field that is not `\"info\"`.\n\n**Escape breakdown by root cause** — uses the `escape_type` field from round-JSON findings:\n- **Implementation escapes**: code violates spec (`escape_type: \"implementation\"`)\n- **Spec escapes**: spec was too permissive (`escape_type: \"spec\"`)\n- **Unclassified**: no `escape_type` field or null value\nMissing or null `escape_type` is counted as \"unclassified.\"\n\n**Escape trends** — for each preset, compare the current cycle's weighted escape score to the previous cycle's score:\n- **Improving**: score decreased\n- **Stable**: score change \u003C= 20%\n- **Regressing**: score change > 20%\nWhen fewer than 2 cycles exist for a preset, report \"insufficient data for trend.\"\n\n**Severity distribution** — per audit cycle, report count of CRITICAL, HIGH, MEDIUM, LOW findings as a table. Note the distribution shift from previous cycle when available.\n\n**Dormant escape metrics** — when no round-JSON files exist in `.correctless\u002Fartifacts\u002Ffindings\u002F`, the entire escape metrics section is dormant — no error, no warning, just omitted from output. Follows PAT-019.\n\n**Phase effectiveness** — from `workflow-effectiveness.json`:\n- For each phase: bugs that should have been caught vs bugs actually caught\n- Identify weak phases (low catch rate relative to responsibility)\n\n**Antipattern trends** — from `.correctless\u002Fantipatterns.md`:\n- Total entries\n- Group by category — which categories keep growing?\n- Most frequent (highest `Frequency` field)\n\n**Drift debt health** — from `.correctless\u002Fmeta\u002Fdrift-debt.json`:\n- Open items count\n- Oldest open item age\n- Items resolved vs items accumulating\n\n**Olympics history** — from audit history files:\n- Number of runs by preset (QA, Hacker, Perf)\n- Average rounds to convergence\n- Total findings across all runs\n- Recurring patterns flagged\n\n**Olympics staleness** — for \"days since last Olympics\" per preset, take the\nmaximum of two independent signals (ABS-029 \u002F PRH-005 — single-signal\nstaleness was the original PMB-005 bug):\n- (a) mtime of `.correctless\u002Fartifacts\u002Ffindings\u002Faudit-{preset}-history.md` if the file exists\n- (b) mtime of the most recent file matching `.correctless\u002Fartifacts\u002Ffindings\u002Faudit-{preset}-*-round-*.json` if any match\n\nUse the `max` of (a) and (b) — the later of the two timestamps wins. If\nneither signal exists, report the staleness as `no data` literally (never\nsilently zero or \"infinite\"). The comparison is strictly mtime-based — do\nNOT cross-check the round-JSON's `started_at` content; that's the gate's\njob (cmd_audit_done in workflow-advance.sh), not the consumer's. Layer\nseparation is intentional.\n\nAcknowledged residual risk: ENV-003 says filesystem mtime is unreliable\nafter `git checkout`\u002F`git clone`. The consumer side accepts this — \u002Fcmetrics\nis advisory and fail-open; a stale mtime produces a slightly-wrong staleness\nnumber but does not corrupt workflow state. The gate (cmd_audit_done) is\ncontent-based and immune to the same drift.\n\n**Audit-done overrides** — count `audit-done` overrides separately from\ntotal overrides in the Override Health section. A routine `audit-done`\noverride is the AP-023 recurrence pattern for the ABS-029 gate specifically.\nSurface as a dedicated counter line: `audit-done overrides: {N} across {M} runs`.\n\n**Feature velocity** — from git log:\n- Average branch duration (first commit to merge)\n- Features per month\n\n## Output Format\n\nPrint to conversation AND write to `.correctless\u002Fartifacts\u002Fmetrics-{date}.md`:\n\n```markdown\n# Correctless Metrics — {Project Name}\n# Generated: {date}\n\n## Overview\n- **Features completed:** {N} (from spec count)\n- **Issues caught pre-merge:** {N} (per-feature gates only — review, test audit, QA, verify)\n- **Issues escaped to audit:** {N} (found by \u002Fcaudit after landing on main)\n- **Issues escaped to production:** {N} (PMBs)\n- **Workflow active since:** {date of first spec file}\n\n## Issues by Phase (Pre-Merge Gates)\n| Phase | Issues Caught | % of Total | Notes |\n|-------|--------------|------------|-------|\n| Review | {N} | {%} | {e.g., \"Security checklist added 40% of these\"} |\n| Test Audit | {N} | {%} | |\n| QA | {N} | {%} | {e.g., \"3 class fixes added structural tests\"} |\n| Verify | {N} | {%} | |\n\n## Escape Rate (Three-Gate Breakdown)\n\n| Gate | Count | Source |\n|------|-------|--------|\n| Per-feature escapes | {N} BLOCKING findings | qa-findings-*.json |\n| Audit escapes | {N} findings (excl. info) | round-JSON in artifacts\u002Ffindings\u002F |\n| Production escapes | {N} post-merge bugs | workflow-effectiveness.json |\n\n### Severity-Weighted Escape Score\n\nPer audit cycle (grouped by `preset` + `date` from round-JSON files):\n\n| Cycle | Preset | Date | Weighted Score | Trend |\n|-------|--------|------|----------------|-------|\n| {N} | {preset} | {date} | {score} | {improving\u002Fstable\u002Fregressing} |\n\nWeights: critical=5, high=3, medium=2, low=1, info=0. Case-insensitive.\nTrend: improving (score decreased), stable (change \u003C= 20%), regressing (change > 20%).\nWhen fewer than 2 cycles exist for a preset: \"insufficient data for trend.\"\n\n### Root Cause Breakdown\n\n| Category | Count | % |\n|----------|-------|---|\n| Implementation escapes | {N} | {%} |\n| Spec escapes | {N} | {%} |\n| Unclassified | {N} | {%} |\n\nUses `escape_type` field from round-JSON findings. Missing\u002Fnull = unclassified.\n\n### Severity Distribution\n\nPer audit cycle:\n\n| Severity | Count | Shift from Previous |\n|----------|-------|--------------------|\n| CRITICAL | {N} | {+\u002F-N or \"—\"} |\n| HIGH | {N} | {+\u002F-N or \"—\"} |\n| MEDIUM | {N} | {+\u002F-N or \"—\"} |\n| LOW | {N} | {+\u002F-N or \"—\"} |\n\n### Production Bug Escapes\n{From workflow-effectiveness.json — unchanged}\n| ID | Severity | What | Phase That Missed | Why |\n|----|----------|------|-------------------|-----|\n| PMB-001 | {sev} | {desc} | {phase} | {reason} |\n\n**Weakest phase:** {phase with most misses relative to responsibility}\n**Recommendation:** {what to improve — more templates? higher intensity? more QA rounds?}\n\n## Antipattern Trends\n- **Total entries:** {N}\n- **Top categories:**\n  | Category | Count | Trend |\n  |----------|-------|-------|\n  | {category} | {N} | {growing\u002Fstable\u002Fresolved} |\n\n- **Most frequent:** {AP-xxx} — {description} — seen {N} times\n\n{If any category has 3+ entries: \"Consider whether this is an architectural issue, not just a code pattern.\"}\n\n## Drift Debt\n- **Open items:** {N}\n- **Oldest:** {DRIFT-xxx} — {age} days — {description}\n- **Resolved this period:** {N}\n- **Accumulating faster than resolving:** {yes\u002Fno}\n\n{If oldest > 60 days: \"Flag for \u002Fcdevadv analysis — this is rotting.\"}\n\n## Olympics History\n| Run | Preset | Date | Rounds | Findings | Fixed |\n|-----|--------|------|--------|----------|-------|\n| 1 | QA | {date} | {N} | {N} | {N} |\n| 2 | Hacker | {date} | {N} | {N} | {N} |\n\n**Average convergence:** {N} rounds\n**Recurring patterns:** {patterns that keep appearing across runs}\n\n## Mini-Audit Lens Coverage\n\nRead lens data from two sources: (1) qa-findings JSON files (`.correctless\u002Fartifacts\u002Fqa-findings-*.json`) for LENS fields on MA- findings, and (2) lens recommendation artifacts (`.correctless\u002Fartifacts\u002Flens-recommendations-*.json`) for recommended vs. actually-ran data. The LENS field is an open enum — handle unknown lens values gracefully (do not error on unrecognized lens names from recommended lenses).\n\n**Dormant (PAT-019)**: When no lens recommendation artifacts exist under `.correctless\u002Fartifacts\u002F`, the Mini-Audit Lens Coverage section is dormant — omitted from output entirely, no error, no warning. Only display this section when at least one `lens-recommendations-*.json` file exists.\n\nWhen data exists, report:\n\n**(a) Lenses ran across recent features** — from qa-findings JSON LENS fields. Count how many times each lens value appeared across features.\n\n**(b) Recommended lenses vs actually ran** — from lens recommendation artifacts. For each feature with a recommendation artifact, show which recommended lenses were suggested and which actually ran (from the `outcomes` field).\n\n**(c) Finding yield per lens** — findings count divided by times the lens ran. Lenses with zero yield across 3+ features may be stale.\n\n**(d) Promotion candidates** — lenses recommended 3+ times across features are flagged as candidates for promotion to the core lens set or for a new PAT-xxx entry in `.correctless\u002FARCHITECTURE.md`.\n\n## Velocity\n- **Average feature duration:** {N} days (branch creation to merge)\n- **Features per month:** {N}\n- **Workflow overhead per feature:** ~{N} min estimated\n\n## Override Health\n\nRead all files in `.correctless\u002Fmeta\u002Foverrides\u002F*.json`. Compute:\n\n**(a) Total overrides** across all preserved runs — sum `override_count` from each file.\n\n**(b) Mean overrides per run** — total overrides \u002F count of preserved files.\n\n**(c) Override reason frequency** — group overrides by reason using Jaccard similarity (threshold 0.3, invoked via `Bash(source scripts\u002Foverride-scrutiny.sh && jaccard_similarity \"reason_a\" \"reason_b\")`) to cluster similar reasons. Show up to 3 clusters sorted by count descending; ties broken alphabetically by shortest reason in the cluster.\n\nThe clustering threshold (0.3) is intentionally lower than the retry-prevention threshold (0.4 in PRH-006) — clustering for reporting should be loose to surface patterns, while retry prevention should be conservative to avoid blocking legitimate overrides.\n\nIf mean overrides per run > 0.5, emit a warning: \"Override rate is elevated ({mean}\u002Frun). Check the top reasons — this may indicate a gate misclassification (AP-023).\"\n\nIf `.correctless\u002Fmeta\u002Foverrides\u002F` doesn't exist or is empty, the section says: \"No override data yet. Override tracking starts automatically on the next `\u002Fcauto` run.\"\n\n## Deferred Findings Backlog Trend\n\nRead `.correctless\u002Fmeta\u002Fdeferred-findings.json`. If the file does not exist, show: \"No deferred findings data.\"\n\nWhen the file exists, display:\n\n- **Total open count**: findings where `status` is `open`\n- **Severity breakdown**: count of MEDIUM, LOW, ADVISORY among open findings\n- **Oldest open finding**: date and feature of the earliest `deferred_at` among open findings\n- **Resolved in last 30 days**: count of findings where `resolved_at` is within the last 30 days (UTC comparison)\n- **Added in last 30 days**: count of findings where `deferred_at` is within the last 30 days\n\nAll date comparisons use ISO-8601 UTC timestamps. The 30-day trend computation is prompt-level (performed by the LLM agent reading the JSON), not a script.\n\n## Fix-Round Loop Activation\n\nRead `fix_rounds_triggered` from each entry in `.correctless\u002Fmeta\u002Fintensity-calibration.json` (ABS-005 consumer — read-only). Filter to entries where `actual_intensity` is `high` or `critical`.\n\nIf `fix_rounds_triggered` is 0 across 3 or more consecutive high+ intensity features, emit a warning: \"Fix-round loop has not fired in {N} consecutive high+ features — severity calibration may be insufficient (AP-028). Consider reviewing QA findings from recent features to check if NON-BLOCKING ratings were appropriate.\"\n\nIf fewer than 3 high+ features exist, omit the warning: \"Insufficient data — fewer than 3 high+ features completed.\"\n\nIf `fix_rounds_triggered` > 0 in recent features, report the activation count: \"Fix-round loop activated in {N}\u002F{M} recent high+ features ({total} fix rounds total).\"\n\n## ROI Estimate\n- **Issues caught pre-merge:** {N} (per-feature gates only)\n- **Issues escaped to audit:** {N} (caught post-merge by \u002Fcaudit)\n- **Estimated fix time if found in production:** {pre-merge caught} × 2 hours avg = {N} hours\n- **Workflow time invested:** {features} × {overhead per feature} = {N} hours\n- **Net time saved:** {production fix time} - {workflow time} = {N} hours\n\n{This is a rough estimate. Production bugs take 2-10x longer to fix than pre-merge bugs due to debugging, hotfixes, rollbacks, and incident response. The 2-hour average is conservative. Audit escapes are excluded from ROI — they were caught post-merge, so the per-feature workflow didn't prevent them.}\n\n## Health Analysis\n- **QA Round Trend:** {e.g., \"Averaging 2.3 rounds — trending down from 3.1 last quarter.\"}\n- **Antipattern Growth:** {e.g., \"Error handling category growing fastest (+4 in 3 months). Consider architectural pattern.\"}\n- **Drift Staleness:** {e.g., \"3 drift items older than 90 days. Schedule \u002Fcdevadv layers analysis.\"}\n- **Olympics Convergence (at high+ intensity):** {e.g., \"Last 5 runs converged in ≤2 rounds — consider rotating presets.\" Omit this bullet at standard intensity.}\n- **Decision Record Staleness:** {e.g., \"2 decisions have expired revisit-by dates.\"}\n- **Spec Revision Rate:** {e.g., \"Specs revised mid-TDD in 60% of features — spec phase may need more brainstorm time.\"}\n- **Cross-Metric Correlations:** {e.g., \"Spec revision rate is high AND antipattern growth is accelerating in error handling — spec phase isn't learning from antipatterns.\"}\n```\n\n## Health Analysis\n\nAfter computing the raw metrics above, analyze them for actionable insights. This is the interpretive layer — raw numbers without analysis are useless.\n\n**QA Round Trends:**\n- Calculate average QA rounds across all features. If trending up across recent features: \"QA is finding more issues — check whether specs are getting less thorough or code quality is degrading.\"\n- If trending down: \"QA rounds are decreasing — the workflow is getting more effective.\"\n- If suspiciously low (every feature passes in 1 round): \"Every feature passes QA in 1 round. Either code quality is exceptional or QA intensity is too low. Consider increasing min_qa_rounds or adding more hostile QA lenses.\"\n\n**Antipattern Growth:**\n- Group antipatterns by category. Flag the fastest-growing: \"Error handling antipatterns are growing fastest (4 new in last 3 months). This may indicate an architectural gap, not just individual bugs.\"\n- If any category has 5+ entries: \"Consider whether '{category}' is a systemic issue that needs an .correctless\u002FARCHITECTURE.md pattern, not just more antipattern entries.\"\n\n**Drift Debt Staleness:**\n- Flag items older than 90 days: \"{N} drift items are older than 90 days. Stale drift becomes invisible — schedule a `\u002Fcdevadv layers` analysis.\"\n- Compare accumulation vs resolution rate: \"Drift is accumulating {N}x faster than it's being resolved.\"\n\n**Olympics Convergence Speed (high+ intensity):**\n- If last 5 runs all converged in ≤2 rounds: \"Olympics are converging suspiciously fast. Possible causes: (1) lenses are stale, (2) codebase is genuinely clean, (3) agent presets need rotation. Try a custom preset.\"\n- If convergence is getting slower: \"Olympics are taking more rounds — new code may be introducing complexity the current lenses don't cover well.\"\n\n**Decision Record Staleness:**\n- Scan `.correctless\u002Fdecisions\u002F` for files with `revisit-when` or `revisit-by` markers. Flag expired conditions.\n\n**Spec Revision Rate:**\n- If specs are frequently revised during TDD (high spec_updates counts across features): \"Specs are being revised mid-TDD frequently. The spec phase may not be thorough enough — consider more Socratic brainstorm time or research steps.\"\n\n**Cross-Metric Correlations (the most valuable insights):**\n- \"Spec revision rate is high AND antipattern growth is accelerating in the same category\" → spec phase isn't learning from antipatterns\n- \"QA rounds are low BUT post-merge bugs are increasing\" → QA is too lenient\n- \"Drift debt is growing AND Olympics convergence is fast\" → drift may be in areas Olympics don't cover\n- \"Review phase catches fewer issues over time BUT antipattern count is growing\" → review isn't reading antipatterns effectively\n\n## Token ROI Analysis\n\nRead all `.correctless\u002Fartifacts\u002Ftoken-log-*.jsonl` files. Correlate token spend with findings data from QA, verification, and audit artifacts.\n\n### Metrics to Compute\n\n**1. Cost per bug caught**: When cost artifacts exist (`.correctless\u002Fartifacts\u002Fcost-*.json`), compute actual USD cost: \"Across {N} features, you spent ${X} and caught {B} bugs — ${X\u002FB} per bug caught pre-merge.\" Falls back to token-count-based estimates when cost artifacts are missing: \"Across {N} features, you spent {T} tokens and caught {B} bugs — {T\u002FB} tokens per bug caught pre-merge.\"\n\n**2. Tokens per feature by phase**: Group all token log entries by the `feature` field and sum `total_tokens` per feature. Show as a table:\n\n| Phase | Tokens | % of Total | Findings | Tokens\u002FFinding |\n|-------|--------|-----------|----------|----------------|\n| TDD (ctdd) | {N} | {%} | {N} | {N} |\n| Review (creview\u002Fcreview-spec) | {N} | {%} | {N} | {N} |\n| Verification (cverify) | {N} | {%} | {N} | {N} |\n| Audit (caudit) | {N} | {%} | {N} | {N} |\n| Other (all remaining: cspec, cdebug, crefactor, cmodel, credteam, cdevadv, cpostmortem) | {N} | {%} | {N} | {N} |\n\nThis shows where the budget goes. If 65% goes to TDD and TDD catches 60% of bugs, the allocation is efficient. If 40% goes to audit and it catches 5% of bugs, consider reducing audit intensity.\n\n**3. Bug escape rate**: From `workflow-effectiveness.json`: `post_merge_bugs` count \u002F (total caught + escaped). \"Escape rate: {N}%. {M} caught pre-merge, {K} escaped.\"\n\n**4. Estimated production fix cost avoided**: Each caught bug saves an estimated 2-10 hours of production debugging, hotfixes, rollbacks, and incident response. \"{N} bugs caught × 2-10 hours = {range} hours saved. At USD 150\u002Fhr developer cost, that's ${range} saved.\" This is a rough estimate — say so. But even the conservative end usually exceeds the token cost.\n\n**5. Tokens per LOC**: Total tokens \u002F total lines added (from git diff --stat across features). Track over time — should be stable if overhead scales linearly.\n\n**6. Olympics efficiency** (high+ intensity): Tokens per finding per round. \"Round 1: {N} findings at {T} tokens. Round {M}: {N} findings at {T} tokens.\" Shows diminishing returns.\n\n**7. Token trend**: Split completed features chronologically into two halves (first N\u002F2 vs second N\u002F2; for odd counts, the middle feature goes to the first half). Compute the average tokens per feature for each half. If the second half average exceeds the first half average by more than 20%, the trend is \"growing\". If the second half average is more than 20% lower than the first half average, the trend is \"shrinking\". Otherwise the trend is \"stable\" (within 20% threshold). If fewer than 4 features have token data, the trend is \"insufficient data\". Report: \"Token cost per feature: {growing\u002Fshrinking\u002Fstable\u002Finsufficient data}. First half average: {N}. Second half average: {N}. Cost per bug: {improving\u002Fdegrading}.\"\n\n**8. Tool call distribution per phase**: From audit trail JSONL files, count tool invocations grouped by phase. Shows where tool activity concentrates — if 80% of Edit calls happen in tdd-impl (GREEN), the implementation phase is the most write-heavy.\n\n### Output\n\nAdd to the dashboard after the existing ROI Estimate section:\n\n```markdown\n## Token ROI Analysis\n\n### Cost Summary\n- **Total tokens tracked:** {N} across {M} features\n- **Average tokens per feature:** {N}\n- **Cost per bug caught:** {N} tokens ({M} bugs caught)\n\n### Phase Distribution\n| Phase | Tokens | % of Total | Findings | Tokens\u002FFinding |\n|-------|--------|-----------|----------|----------------|\n| TDD (ctdd) | {N} | {%} | {N} | {N} |\n| Review (creview, creview-spec) | {N} | {%} | {N} | {N} |\n| Verification (cverify) | {N} | {%} | {N} | {N} |\n| Audit (caudit) | {N} | {%} | {N} | {N} |\n| Other (cspec, cdebug, crefactor, cmodel, credteam, cdevadv, cpostmortem) | {N} | {%} | {N} | {N} |\n\n### Per-Feature Token Cost\n\nRead all `token-log-*.jsonl` files from `.correctless\u002Fartifacts\u002F`. Produce a per-feature token cost table alongside the Phase Distribution table. Each row represents one feature. Extract the feature slug from the JSONL filename (the portion between `token-log-` and `.jsonl`).\n\nColumns: feature slug, total tokens, tokens by skill category (TDD, Review, Verification, Audit, Other), and QA rounds.\n\nUse the JSONL `skill` field for category mapping:\n- ctdd maps to TDD\n- creview\u002Fcreview-spec maps to Review\n- cverify maps to Verification\n- caudit maps to Audit\n- all others map to Other\n\nRead QA rounds from the workflow state file (`.correctless\u002Fartifacts\u002Fworkflow-state-{slug}.json`, field `qa_rounds`) for each feature. If no workflow state file exists for a feature, show \"–\" in the QA Rounds column. If a JSONL entry lacks a `skill` field, infer the category from the `phase` field using the same mapping.\n\nThe table is sorted by total tokens descending. If no token log files exist, skip this section with a note: \"No token log data available.\"\n\n| Feature Slug | Total Tokens | TDD | Review | Verification | Audit | Other | QA Rounds |\n|-------------|-------------|-----|--------|-------------|-------|-------|-----------|\n| {slug} | {N} | {N} | {N} | {N} | {N} | {N} | {N} |\n\n### Bug Escape Rate\n- **Pre-merge bugs caught:** {N}\n- **Post-merge bugs escaped:** {M}\n- **Escape rate:** {%}\n- **Estimated production fix cost avoided:** {N bugs} × 2-10 hours = {range} hours (~${range} at USD 150\u002Fhr)\n\n### Efficiency\n- **Tokens per LOC:** {N} (total tokens \u002F lines added across features)\n- **Olympics efficiency (high+ intensity):** Round 1: {N} findings at {T}k tokens → Round {M}: {N} findings at {T}k tokens\n\n### Token Trend\n- Token cost per feature: {growing\u002Fshrinking\u002Fstable\u002Finsufficient data} (first half average vs second half average, 20% threshold)\n- Cost per bug caught: {improving\u002Fdegrading}\n```\n\nIf no token logs exist, skip this section with: \"No token usage data yet. Token tracking starts automatically when skills run — data will appear after the next feature.\"\n\n## Session Analytics (from Claude Code data)\n\nDetermine the current project root: `git rev-parse --show-toplevel`. Then use `find ~\u002F.claude\u002Fusage-data\u002Fsession-meta\u002F -name '*.json'` to list all session-meta files (do NOT use Glob with `~` — use find or Bash for tilde expansion). Filter to sessions where `project_path` matches the project root (exact string match on the absolute path). For each matching session, look up the corresponding facets file at `~\u002F.claude\u002Fusage-data\u002Ffacets\u002F{session_id}.json` (the facets filename IS the session_id).\n\nNote: Not all sessions have facets files (~26% coverage is typical). When computing facets-based metrics, note the sample size: \"Outcome data available for {N} of {M} sessions ({%}).\"\n\n### Metrics to Compute\n\n**From session-meta:**\n\n- **Exact token cost**: Sum `input_tokens + output_tokens` across all project sessions. This is ground truth — cross-check against manual token logs. If they diverge significantly, note: \"Session-meta shows {N} tokens total. Token logs show {M}. The difference ({D}) is orchestrator overhead not captured by subagent tracking.\"\n- **Average session duration**: `mean(duration_minutes)` across sessions.\n- **Tool distribution**: Aggregate `tool_counts` across sessions. Show top 6 tools by call count.\n- **Friction rate**: `sum(tool_errors) \u002F sum(all tool calls)`. Break down by `tool_error_categories`.\n- **User engagement**: Average `user_response_times`. Long times (>60s) suggest confusion. Short times (\u003C15s) suggest flow.\n\n**From facets:**\n\n- **Outcome rate**: % of sessions with `outcome: \"fully_achieved\"`.\n- **Satisfaction**: Distribution of `claude_helpfulness` values.\n- **Top friction categories**: Aggregate `friction_counts` across sessions. Flag growing categories.\n\n**Correctless vs Freeform comparison:**\n\nIdentify Correctless sessions by checking whether Correctless artifacts were modified during the session's time window. A session is \"Correctless\" if:\n- Workflow state files (`.correctless\u002Fartifacts\u002Fworkflow-state-*.json`) have `phase_entered_at` timestamps within the session's `start_time` to `start_time + duration_minutes` range, OR\n- The session's `tool_counts` includes calls to tools that only Correctless uses (the `Task` tool with high counts suggests orchestrated workflow), OR\n- QA findings, verification reports, or spec files were modified during the session window (check git log timestamps)\n\nIf none of these signals are present, the session is \"freeform.\" Note: this heuristic is approximate — some Correctless sessions (e.g., `\u002Fcstatus` or `\u002Fchelp`) may look freeform. Err on the side of undercounting Correctless sessions rather than overcounting.\n\n**Important:** Slash commands like `\u002Fcspec` are intercepted by Claude Code before reaching the conversation — they do NOT appear in `first_prompt`. Do not use `first_prompt` to identify Correctless sessions.\n\n### Output\n\n```markdown\n## Session Analytics\n\n### Overview\n- **Sessions tracked:** {N} (from {date} to {date})\n- **Average session duration:** {N} minutes\n- **Total tokens (ground truth):** {N} input + {N} output\n\n### Tool Distribution\n| Tool | Calls | % of Total |\n|------|-------|-----------|\n| {tool} | {N} | {%} |\n\n### Quality Signals\n- **Outcome rate:** {N}% fully achieved\n- **Helpfulness:** {distribution}\n- **Friction rate:** {N}% tool errors\n- **Top friction:** {category from facets friction_counts} ({N} occurrences)\n- **User engagement:** avg response time {N}s ({\u003C15s: flowing | 15-60s: normal | >60s: confused})\n\n### Correctless vs Freeform\n| Metric | Correctless Sessions | Freeform Sessions |\n|--------|---------------------|-------------------|\n| Outcome rate | {%} | {%} |\n| Friction rate | {%} | {%} |\n| Avg duration | {N} min | {N} min |\n| Avg tokens | {N} | {N} |\n```\n\nIf no session-meta data exists for this project, skip with: \"No Claude Code session data found for this project. Session analytics will appear after running a few sessions.\"\n\n## Trend Tracking\n\nIf previous metrics files exist (`.correctless\u002Fartifacts\u002Fmetrics-*.md`), compare:\n- Is the bug escape rate improving? (should decrease over time)\n- Are more issues being caught earlier? (review should catch more as templates improve)\n- Is drift debt accumulating or resolving?\n- Are Olympics converging faster? (should, as antipatterns grow)\n\nNote trends: \"Bug escape rate: 5% → 3% → 1.5% over 3 months. The workflow is getting more effective.\"\n\n## Claude Code Feature Integration\n\n### Task Lists\nUse TaskCreate\u002FTaskUpdate:\n- Reading QA findings (N files)\n- Reading verification reports (N files)\n- Reading workflow effectiveness data\n- Reading antipatterns\n- Reading drift debt\n- Reading Olympics history\n- Reading git log\n- Calculating metrics\n- Reading decision records\n- Reading session analytics data\n- Analyzing health indicators\n- Reading token logs and computing ROI\n- Generating dashboard\n\n## Autonomous Defaults\n\n- **AD-001**: Report scope — generate full metrics dashboard (default). No human input required; this skill runs to completion autonomously.\n\n## If Something Goes Wrong\n\n- `\u002Fcmetrics` writes a dashboard artifact but does not modify workflow state or source code. Re-run anytime safely.\n- If metrics are sparse, that's normal for new projects — data accumulates with each feature. Key sources: QA findings from `\u002Fctdd`, verification reports from `\u002Fcverify`, antipatterns from `\u002Fcpostmortem`.\n\n## Constraints\n\n- **Read-only.** This skill aggregates data. It does not modify anything.\n- **Be honest about estimates.** The ROI calculation is rough. Say so. Don't oversell.\n- **Missing data is normal.** A new project will have sparse metrics. Report what exists and note what will accumulate with more features.\n- **Don't compare to other projects.** Each project's metrics only compare to its own history.\n- **The \"issues caught\" number includes deduplication.** If review and QA both caught the same issue, count it once at the earliest phase.\n- **Redact if sharing.** If this output will be shared externally, apply redaction rules from `templates\u002Fredaction-rules.md` first.\n\nFor a full project dashboard, run `\u002Fcdashboard` and open `.correctless\u002Fdashboard\u002Findex.html` in a browser.\n",{"name":5,"description":7,"allowed-tools":53,"disallowed-tools":54,"interaction_mode":37},"Read, Grep, Glob, Bash(git*), Bash(wc*), Bash(find*), Bash(cat*), Bash(jq*), Write(.correctless\u002Fartifacts\u002Fmetrics-*)","Edit, MultiEdit, NotebookEdit, CreateFile","main","74f9ef3f5acae9c857f6be6dd86cdc3b10830c90","skills\u002Fcmetrics",4,"https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless","https:\u002F\u002Fjoshft.github.io\u002Fcorrectless\u002F","https:\u002F\u002Fgithub.com\u002Fjoshft","2026-11-14 02:53:56",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add joshft\u002Fcorrectless --skill cmetrics",{"tool":69,"command":70},"bunx","bunx skills add joshft\u002Fcorrectless --skill cmetrics",{"tool":72,"command":73},"pnpm","pnpm dlx skills add joshft\u002Fcorrectless --skill cmetrics","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcmetrics\u002FSKILL.md",true,[],[78,98,121,139,156,170],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":87,"publishedAt":48},"01M6JJW224Q40TCVMTKRZPDHDY","cwtf","Audit the workflow itself. Use when you suspect agents shortcut or after a bug escapes despite the workflow running. Checks phase execution, rule coverage, and agent thoroughness.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcwtf\u002FSKILL.md",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[80,38,45,44,88,89,41,90,91,92,40,39,29,93,37,35,94,95,96,97],"audit","execution","grep","find","jq","coverage","wtf","bug","you","shortcut",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":108,"publishedAt":48},"01M6JJVT9M4KGWQ99V0CSF6WZ5","cverify","Verify implementation matches spec. Check rule coverage, undocumented dependencies, architecture compliance. Writes verification report and drift debt. Run after \u002Fctdd completes.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcverify\u002FSKILL.md",[104,105],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":106,"categoryName":107,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务",[100,109,38,110,111,45,112,113,41,40,39,29,93,114,115,116,117,118,119,120],"go","architecture","run","verification","Meta","diff","ruff","drift","verify implementation","cargo","stryker","ctdd",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":48},"01M6JJVP2E6BHHKF3SCMDXG0S2","cupdate-arch","Update .correctless\u002FARCHITECTURE.md after features land. Use after \u002Fcdocs or when the codebase structure has changed.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcupdate-arch\u002FSKILL.md",[],[128,129,130,110,131,45,132,41,133,90,40,39,29,35,134,135,136,137,138],"arch","cupdate arch","docs","update","land","Rules","structure","codebase","features","codebase structure","cdocs",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":48},"01M6JJVJVZ72KVWN1K3RWQK0YJ","ctriage","Bulk triage deferred findings backlog. Presents findings one at a time with disposition options.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fctriage\u002FSKILL.md",[],[141,146,113,41,147,90,92,148,40,39,29,149,150,151,152,153,154,155],"triage","json","one at a time","interactive","options","backlog","time","bulk","with","at",{"skillNo":157,"name":120,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":48},"01M6JJVCYCNYD4GHK33DZE9DXA","Enforced TDD workflow. Write failing tests from spec rules, then implement. Use after \u002Fcreview approves a spec.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fctdd\u002FSKILL.md",[161],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},[120,163,164,165,38,44,166,41,133,90,40,39,29,35,167,168,169],"spec","implement","tdd","tdd workflow","task","tests","creview",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":48},"01M6JJV7S3EQG3GHQ56DD8P1SA","csummary","Feature summary. Use after \u002Fcdocs to see what the workflow caught, or mid-feature to check progress.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcsummary\u002FSKILL.md",[],[172,38,45,44,41,90,177,40,39,29,37,35,178,179,180,181,138],"check","what the","summary","feature","progress"]