From harness-claude
Identifies structural hotspots via co-change patterns and churn analysis using git history or Harness knowledge graph. Run before refactoring, for weekly risk tracking, or break investigations.
npx claudepluginhub intense-visions/harness-engineering --plugin harness-claudeThis skill uses the workspace's default tool permissions.
> Identify modules that represent structural risk via co-change and churn analysis.
Identifies riskiest codebase files using git churn analysis, complexity metrics, coupling, and lenskit risk scores for technical debt hotspots.
Analyzes impact of code changes using knowledge graph to identify affected files, tests, docs, components. Use before PR merges, refactors, test failure debugging.
Identifies and explains churn hotspots and unstable code clusters in git repos. Groups by directory, filename stems (e.g. foo.go + foo_test.go), and co-changes; classifies as unstable, buggy, tightly-coupled, etc.
Share bugs, ideas, or general feedback.
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.