From harness-claude
Identifies code modules with structural risk by analyzing co-change patterns and churn. Uses a knowledge graph or git log fallback to detect hidden coupling and high-change areas.
How this skill is triggered — by the user, by Claude, or both
Slash command
/harness-claude:harness-hotspot-detectorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> Identify modules that represent structural risk via co-change and churn analysis.
Identify modules that represent structural risk via co-change and churn analysis.
A knowledge graph at .harness/graph/ with git history enables full analysis. If no graph exists,
the skill uses static analysis fallbacks (see Graph Availability section).
Run harness scan to enable graph-enhanced analysis.
Before starting, check if .harness/graph/graph.json exists.
If graph exists: Use graph tools as primary strategy. (Staleness sensitivity: Low — never auto-refresh. Git-based churn data in the graph remains useful even when slightly stale.)
If graph exists and is fresh (or refreshed): Use graph tools as primary strategy.
If no graph exists: Output "Running without graph (run harness scan to
enable full analysis)" and use fallback strategies for all subsequent steps.
Query the graph for co_changes_with edges (created by GitIngestor):
query_graph(rootNodeIds=[all file nodes], includeEdges=["co_changes_with"])
Identify file pairs that frequently change together:
Flag distant co-change pairs as potential hotspots.
Query commit nodes to find files with the highest change frequency:
query_graph(rootNodeIds=[commit nodes], includeTypes=["commit", "file"], includeEdges=["co_changes_with"])
Rank files by:
High churn in shared utilities or core modules = high risk.
When no graph is available, git log provides nearly all the data needed (~90% completeness):
git log --format="%H" -- <file> for each source file (use glob to enumerate). Count commits per file. Sort descending to rank by churn.git log --since="30 days ago" --format="%H" -- <file> vs git log --since="60 days ago" --until="30 days ago" --format="%H" -- <file> to compare recent vs prior 30-day windows.git log --format="%H %n" --name-only to build a map of which files changed together in the same commit. File pairs that appear together in >3 commits are co-change candidates.wc -l) as a rough proxy for complexity when graph complexity metrics are unavailable.Fallback completeness: ~90% — git log provides nearly all the data the graph stores for this use case.
Cross-reference co-change data with structural data:
High logical coupling, low structural coupling: Files that always change together but have no imports edge between them. This indicates a hidden dependency — changing one requires changing the other, but the code doesn't express this relationship.
High structural coupling, low logical coupling: Files with imports edges but that rarely change together. This may indicate over-coupling — the import exists but the relationship is weak.
Use get_relationships to check structural edges between co-change pairs.
## Hotspot Analysis Report
### Risk Hotspots (ranked by risk score)
1. **src/services/billing.ts** — Risk: HIGH
- Churn: 23 commits (last 30 days: 8)
- Co-changes with: src/types/invoice.ts (distant, 15 co-changes)
- Hidden dependency: no imports edge to invoice.ts
- Recommendation: Extract shared billing types or add explicit dependency
2. **src/utils/helpers.ts** — Risk: HIGH
- Churn: 45 commits (highest in codebase)
- Co-changes with: 12 different files across 4 modules
- Recommendation: Split into domain-specific utilities to reduce blast radius
3. **src/middleware/auth.ts** — Risk: MEDIUM
- Churn: 15 commits
- Co-changes with: src/routes/login.ts (co-located, expected)
- No hidden dependencies detected
### Summary
- Total hotspots detected: 5
- High risk: 2
- Medium risk: 3
- Hidden dependencies: 1
harness scan — Recommended before this skill for full graph-enhanced analysis. If graph is missing, skill uses git log fallbacks.harness validate — Run after acting on findings to verify project health.query_graph, get_impact, and get_relationships MCP tools.These are common rationalizations that sound reasonable but lead to incorrect results. When you catch yourself thinking any of these, stop and follow the documented process instead.
| Rationalization | Why It Is Wrong |
|---|---|
| "High churn just means the file is actively developed, not that it is risky" | High churn in shared utilities specifically equals high risk. A file with 45 commits that co-changes with 12 different files indicates hidden coupling. |
| "The co-change pair is between two files in different modules, but they probably just happen to change at the same time" | Distant co-change pairs are flagged as suspicious precisely because they indicate hidden coupling. |
| "No graph exists so the analysis will be too incomplete to be useful" | Git log provides ~90% of the data needed for hotspot detection. The fallback is the highest-completeness fallback across all graph-enhanced skills. |
Input: Scheduled weekly analysis on project root
1. CO-CHANGE — query_graph for co_changes_with edges
Found 4 distant co-change pairs
2. CHURN — Ranked files by commit frequency
billing.ts: 23 commits, helpers.ts: 45 commits
3. COUPLING — Cross-referenced co-change vs imports edges
billing.ts <-> invoice.ts: 15 co-changes, no imports edge
(hidden dependency detected)
4. REPORT — Ranked hotspots by risk score
Output:
Hotspots: 5 total (2 high, 3 medium)
Hidden dependencies: 1 (billing.ts <-> invoice.ts)
Top recommendation: Extract shared billing types
co_changes_with edges when available; use git log commit analysis when not. Do not guess — parse actual git history.npx claudepluginhub intense-visions/harness-engineering --plugin harness-claudeIdentifies riskiest codebase files using git churn analysis, complexity metrics, coupling, and lenskit risk scores for technical debt hotspots.
Performs graph-based impact analysis to answer 'if I change X, what breaks?' before merging PRs or planning refactors.
Analyzes git history to detect churn hotspots and unstable code clusters, classifying them by cause (unstable, buggy, tightly-coupled, etc.) with explanations. Used when asked about hotspots, technical debt, or "what's a mess" in a repo.