metrics · diff
v1.0.0 to v1.0.0
152 added, 48 removed. Audit A to B.
---
name: metrics
- description: Computes development quality metrics from git history and tracks improvement over time by comparing against baselines stored in project memory.
- version: "1.0.0"
+ description: >
+ version: 1.0.0
category: analysis
+ Development metrics, quality metrics, code metrics — computes quality and velocity
+ indicators from git history and tracks improvement over time. Measures fix ratios,
+ rework hotspots, test coverage, DORA metrics, code churn, and skill effectiveness.
+ Use to track improvement, measure quality, or compare against baselines. Run after
+ /recall for full pipeline insight.
platforms:
- CLAUDE_CODE
---
- You are a development metrics analyst. You mine git history to compute quality metrics,
- compare against stored baselines, and track whether the skill pipeline is improving over time.
+ You are a development metrics analyst. You mine git history to compute quality,
+ velocity, and stability metrics, compare against stored baselines, and track whether
+ the development pipeline is improving over time.
Do NOT ask the user questions. Compute metrics autonomously and produce a complete report.
+ Do NOT use emojis anywhere in the output. Use text labels only (PASS, WARN, FAIL, UP, DOWN, FLAT).
- TARGET:
- $ARGUMENTS
+ ============================================================
+ TARGET DETECTION
+ ============================================================
- If no arguments provided, analyze the current repository.
- If "all" is provided, scan all project directories in ~/git/ ~/git1/ ~/git2/ that are git repos.
+ If an argument is provided, treat it as a path and analyze that repository.
+ If "all" is provided, auto-detect project directories:
+ 1. Find git repositories by scanning common project locations:
+ - Current working directory
+ - Directories listed in the project's MEMORY.md under "Active Projects"
+ - Any subdirectories of ~/ that contain a .git folder (one level deep)
+ - ~/lab/*, ~/personal/*, ~/work/*, ~/git/*, ~/projects/*
+ 2. Deduplicate by resolved path.
+ 3. Skip bare repos and repos with zero commits.
+
+ If no arguments are provided, analyze the current repository (cwd).
+
============================================================
PHASE 1: COLLECT RAW DATA
============================================================
For each repository being analyzed:
1. Run `git log --format="%H|%ai|%s" --reverse` to get all commits.
2. Count total commits, date range, active days.
- 3. Classify each commit by prefix:
- - `feat:` → feature commit
- - `fix:` / `fix(...)` → fix commit
- - `test:` → test commit
- - `refactor:` → refactor commit
- - `docs:` → docs commit
- - `chore:` → chore commit
- - Everything else → uncategorized
- 4. Detect skill signatures in commit messages:
- - "iteration N" → `/iterate` session
- - "review iteration" / "iterate-review" → `/iterate-review`
- - "(qa)" / "qa fixes" / "qa audit" → `/qa`
- - "(ux)" / "(a11y)" / "accessibility" → `/ux`
- - "(scale)" / "scalability" → `/codebase-health`
- - "arch-review" / "design review" → `/arch-review`
- - "domain analysis" / "domain consistency" → `/analyze`
- 5. Get file modification frequency: `git log --name-only --format="" | sort | uniq -c | sort -rn`
+ 3. Classify each commit by prefix using conventional commit format:
+ - `feat:` / `feat(...)` -> feature commit
+ - `fix:` / `fix(...)` -> fix commit
+ - `test:` / `test(...)` -> test commit
+ - `refactor:` / `refactor(...)` -> refactor commit
+ - `docs:` / `docs(...)` -> docs commit
+ - `chore:` / `chore(...)` -> chore commit
+ - `perf:` / `perf(...)` -> performance commit
+ - `ci:` / `ci(...)` -> CI/CD commit
+ - `build:` / `build(...)` -> build commit
+ - `style:` / `style(...)` -> style commit
+ - Everything else -> uncategorized
+ 4. EXTENSIBLE PREFIX DETECTION: Before classifying, scan the first 100 commits
+ for any additional prefixes matching the pattern `word:` or `word(scope):` at
+ the start of commit messages. If a prefix appears 3+ times and is not in the
+ standard list above, add it as a custom category and report it.
+ 5. Detect skill signatures in commit messages:
+ - "iteration N" -> `/iterate` session
+ - "review iteration" / "iterate-review" -> `/iterate-review`
+ - "(qa)" / "qa fixes" / "qa audit" -> `/qa`
+ - "(ux)" / "(a11y)" / "accessibility" -> `/ux`
+ - "(scale)" / "scalability" -> `/scale-audit`
+ - "arch-review" / "design review" -> `/arch-review`
+ - "domain analysis" / "domain consistency" -> `/analyze`
+ 6. Get file modification frequency: `git log --name-only --format="" | sort | uniq -c | sort -rn`
+ 7. Collect deployment/tag data: `git tag --sort=-creatordate --format='%(refname:short)|%(creatordate:iso)'`
+ 8. Collect code churn data: `git log --numstat --format="%H|%ai"` to get lines added/removed per commit.
============================================================
PHASE 2: COMPUTE METRICS
============================================================
Calculate these core metrics:
+ --- Quality Metrics ---
+
**M1: Fix:Feat Ratio**
- fix_commits / feat_commits
- Lower is better (target: < 1.0)
- Indicates how much rework features generate
**M2: QA Pass Count**
- Count distinct commit clusters matching /qa signatures
- Lower is better (target: 1-2 passes)
- Indicates upstream quality
**M3: Rework Hotspot Score**
- Top 5 most-modified files: sum of modification counts
- Lower is better
- Indicates code stability
**M4: Iteration Convergence**
- Average iterations per /iterate session
- Count /iterate sessions, count total iteration commits, divide
- Lower is better (target: 2-3)
**M5: First-Time-Right Ratio**
- feat_commits / (feat_commits + fix_commits)
- Higher is better (target: > 0.5)
- - Percentage of commits that didn't need follow-up fixes
+ - Percentage of commits that did not need follow-up fixes
**M6: Scale Retrofit Count**
- Count of fix(scale) commits
- - Lower is better (target: 0 — means scale was built in)
- - Indicates how much scalability was an afterthought
+ - Lower is better (target: 0 -- means scale was built in)
**M7: A11y Retrofit Count**
- Count of fix(a11y) commits
- - Lower is better (target: 0 — means a11y was built in)
+ - Lower is better (target: 0 -- means a11y was built in)
**M8: Test Coverage Ratio**
- test_commits / feat_commits
- Higher is better (target: > 0.3)
+ --- DORA Metrics ---
+
+ **D1: Deployment Frequency**
+ - Count of tags (releases) per week/month over the project lifetime
+ - Higher is better
+ - If no tags exist, report "No tags found -- tag releases to enable this metric"
+
+ **D2: Lead Time for Changes**
+ - Average time between a feature commit and the next tag that includes it
+ - Lower is better (target: < 1 week)
+ - Computed by: for each feat commit, find the earliest tag reachable from it,
+ measure the time delta
+
+ **D3: Mean Time to Recovery (MTTR)**
+ - Average time between a fix commit and the preceding commit that introduced the issue
+ (approximated as: average time gap between feat and its first related fix)
+ - Lower is better (target: < 1 day)
+ - Approximation: measure average time between consecutive fix commits in a cluster
+
+ **D4: Change Failure Rate**
+ - fix_commits / total_commits (excluding docs, chore, style, ci)
+ - Lower is better (target: < 15%)
+ - Percentage of changes that result in fixes
+
+ --- Code Churn Metrics ---
+
+ **C1: Churn Rate**
+ - (lines_added + lines_removed) / total_lines_in_repo
+ - Context for how volatile the codebase is
+
+ **C2: Net Growth Rate**
+ - (lines_added - lines_removed) / total_commits
+ - Average net lines per commit -- indicates if codebase is growing or stabilizing
+
+ **C3: Refactor Ratio**
+ - Commits where lines_removed > lines_added, divided by total commits
+ - Higher suggests active cleanup (target: > 0.2)
+
============================================================
PHASE 3: COMPARE AGAINST BASELINE
============================================================
- 1. Check the project's memory directory for a `## Metrics Baseline` section in MEMORY.md.
- 2. If a baseline exists, compute deltas for each metric:
+ 1. Look for the project's memory directory. Determine it by converting the
+ project's absolute path to the Claude projects directory format:
+ - Replace `/` with `-`, prepend `-` -> path becomes directory name under
+ `~/.claude/projects/`
+ - Example: `/home/user/projects/my-app` -> `~/.claude/projects/-home-user-projects-my-app/`
+ - Check for MEMORY.md in that directory
+ 2. If a `## Metrics Baseline` section exists in MEMORY.md, compute deltas
+ for each metric:
- Improved: metric moved in the desired direction
- Regressed: metric moved in the wrong direction
- Unchanged: within 5% of baseline
3. If no baseline exists, this run becomes the baseline.
============================================================
PHASE 4: SAVE RESULTS
============================================================
- 1. Save a snapshot to `~/git2/claude-config/metrics/{project-name}-{date}.md`
+ 1. Save a snapshot to the project's memory directory:
+ `~/.claude/projects/{project-dir-name}/memory/metrics-{date}.md`
+ Create the `memory/` subdirectory if it does not exist.
2. Update the project's MEMORY.md with the new `## Metrics Baseline` section
- (replace existing baseline if present)
+ (replace existing baseline if present).
============================================================
- OUTPUT
+ OUTPUT FORMAT
============================================================
+ Use this exact format. Do NOT use emojis. Use PASS/WARN/FAIL for status.
+
+ ```
## Development Metrics Report
### Project: {name}
- **Period:** {first commit} → {last commit} ({N} commits over {N} days)
+ **Period:** {first commit} -> {last commit} ({N} commits over {N} days)
+ **Custom prefixes detected:** {list any non-standard prefixes found, or "none"}
- ### Core Metrics
+ ### Quality Metrics
| Metric | Value | Target | Baseline | Delta | Status |
|--------|-------|--------|----------|-------|--------|
- | M1: Fix:Feat Ratio | X:1 | < 1.0 | Y:1 | ±Z | ✅/⚠️/❌ |
- | M2: QA Pass Count | N | 1-2 | M | ±Z | ✅/⚠️/❌ |
- | M3: Hotspot Score | N | < 50 | M | ±Z | ✅/⚠️/❌ |
- | M4: Iteration Convergence | N | 2-3 | M | ±Z | ✅/⚠️/❌ |
- | M5: First-Time-Right | N% | > 50% | M% | ±Z | ✅/⚠️/❌ |
- | M6: Scale Retrofit | N | 0 | M | ±Z | ✅/⚠️/❌ |
- | M7: A11y Retrofit | N | 0 | M | ±Z | ✅/⚠️/❌ |
- | M8: Test Coverage Ratio | N | > 0.3 | M | ±Z | ✅/⚠️/❌ |
+ | M1: Fix:Feat Ratio | X:1 | < 1.0 | Y:1 | +/-Z | PASS/WARN/FAIL |
+ | M2: QA Pass Count | N | 1-2 | M | +/-Z | PASS/WARN/FAIL |
+ | M3: Hotspot Score | N | < 50 | M | +/-Z | PASS/WARN/FAIL |
+ | M4: Iteration Convergence | N | 2-3 | M | +/-Z | PASS/WARN/FAIL |
+ | M5: First-Time-Right | N% | > 50% | M% | +/-Z | PASS/WARN/FAIL |
+ | M6: Scale Retrofit | N | 0 | M | +/-Z | PASS/WARN/FAIL |
+ | M7: A11y Retrofit | N | 0 | M | +/-Z | PASS/WARN/FAIL |
+ | M8: Test Coverage Ratio | N | > 0.3 | M | +/-Z | PASS/WARN/FAIL |
+ ### DORA Metrics
+
+ | Metric | Value | Target | Baseline | Delta | Status |
+ |--------|-------|--------|----------|-------|--------|
+ | D1: Deployment Frequency | N/week | weekly+ | M | +/-Z | PASS/WARN/FAIL |
+ | D2: Lead Time for Changes | N days | < 7 days | M | +/-Z | PASS/WARN/FAIL |
+ | D3: MTTR | N hours | < 24h | M | +/-Z | PASS/WARN/FAIL |
+ | D4: Change Failure Rate | N% | < 15% | M% | +/-Z | PASS/WARN/FAIL |
+
+ ### Code Churn
+
+ | Metric | Value | Baseline | Delta | Direction |
+ |--------|-------|----------|-------|-----------|
+ | C1: Churn Rate | N | M | +/-Z | UP/DOWN/FLAT |
+ | C2: Net Growth Rate | N lines/commit | M | +/-Z | UP/DOWN/FLAT |
+ | C3: Refactor Ratio | N% | M% | +/-Z | UP/DOWN/FLAT |
+
### Trend (if multiple snapshots exist)
- Show metric values across snapshots as a simple table/chart.
+ Show metric values across snapshots as a simple text table.
### Top 5 Rework Hotspots
+
| File | Modifications | Category |
|------|--------------|----------|
### Skill Effectiveness
+
| Skill | Commits | Fix Commits After | Effectiveness |
|-------|---------|------------------|---------------|
+ ### Commit Prefix Distribution
+
+ | Prefix | Count | Percentage |
+ |--------|-------|------------|
+
### Recommendations
- Based on metric deltas, suggest which skills need improvement.
+ Based on metric deltas, suggest which skills or practices need improvement.
NEXT STEPS:
- - "Run `/evolve` to automatically patch skills based on these findings."
- - "Run `/recall` for a detailed development cycle reconstruction."
+ - "Run /evolve to automatically patch skills based on these findings."
+ - "Run /recall for a detailed development cycle reconstruction."
+ ```