code-quality-trends
Skill4 starsChanged 6 months agoApache-2.0View on GitHub
Use when checking code quality trends, tech debt accumulation, TODO/FIXME growth, test coverage ratios, PR size distribution, or generating a code quality report. Trigger phrases: code quality, code trends, tech debt trends, quality report.
In this repository57 other files it gives its agents.
- autopilotSkill
- build-python-librarySkill
- build-temporalSkill
- canon-design-reviewSkill
- canon-pr-reviewSkill
- canon-reviewSkill
- ccr-modelsSkill
- ccr-runSkill
- chartSkill
- ci-health-reportSkill
- competitive-matrixSkill
- councilSkill
- create-skillSkill
- deep-debug-ensemble-v1Skill
- deep-debugSkill
- deep-designSkill
- deep-ideaSkill
- deep-planSkill
- deep-qa-ensemble-v1Skill
- deep-qaSkill
- deep-researchSkill
- dependency-auditSkill
- deploy-status-reportSkill
- develop-board-gameSkill
- diagramSkill
- docxSkill
- dora-lite-reportSkill
- find-skillSkill
- flaky-test-diagnoserSkill
- gap-finderSkill
- gen-crash-testSkill
- gen-smokeSkill
- goal-managerSkill
- init-github-repoSkill
- loop-until-doneSkill
- magic-fetchSkill
- ml-pipeline-reportSkill
- monitorSkill
- napSkill
- pipeline-health-reportSkill
- platform-friction-detectorSkill
- pptxSkill
- prod-readinessSkill
- prompt-clash-ensembleSkill
- prompt-clashSkill
- retrospectSkill
- slack-digestSkill
- slidesSkill
- specSkill
- sprint-retroSkill
- tableSkill
- team-temporalSkill
- timelineSkill
- update-stop-gateSkill
- user-activity-reportSkill
- vc-gauntletSkill
- xlsxSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 4 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 37
Use keyword_search with query repo:^{repo}$ (TODO|HACK|FIXME) to count current occurrences.
- Very specific: line 38
Use diff_search with pattern="TODO|HACK|FIXME", added=true, after="{lookback_days} days ago", useRegex=true to count newly added markers in …
- Very specific: line 39
Use diff_search with pattern="TODO|HACK|FIXME", removed=true, after="{lookback_days} days ago", useRegex=true to count removed markers in …
- Very specific: line 43
Use keyword_search with query repo:^{repo}$ file:test type:path count:all to count test files.
- Very specific: line 44
Use keyword_search with query repo:^{repo}$ file:\.(py|java|ts|js|go|kt|scala)$ type:path count:all to count source files (exclude test …
- Very specific: line 57
Check for large files or binary additions: Use diff_search with pattern matching large additions (files with >500 added lines in a single …
- Distinctive: line 101
Deterministic math first, LLM narrates only: All counts, ratios, and distributions must be computed from actual search results and PR data.
- Distinctive: line 102
Pair metrics with counter-metrics: Never report PR velocity without PR size.
- Distinctive: line 106
Count, don't estimate: Every number comes from a Sourcegraph search or gh CLI result.
- Distinctive: line 110
Filter PRs to the lookback window: Don't include PRs merged before the reporting period.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Code Quality Trends Report
Produce a monthly trends report tracking code quality signals across repositories using Sourcegraph and GitHub CLI tools. The report measures TODO/HACK/FIXME accumulation, test file ratios, and PR merge patterns.
Configuration
See _shared/report-config.md for the standard config resolution pattern.
Config schema (~/.claude/skills/code-quality-trends/config.json):
repos: list of repository name strings (Sourcegraph-compatible format)lookback_days: number (default: 30)
Required scope: at least one repos entry.
Arguments
- repos: list of repository names to track (Sourcegraph-compatible format)
- lookback_days: how far back to analyze (default: 30)
Workflow
- Measure TODO/HACK/FIXME accumulation. For each repo:
- Use
keyword_searchwith queryrepo:^{repo}$ (TODO|HACK|FIXME)to count current occurrences. - Use
diff_searchwithpattern="TODO|HACK|FIXME",added=true,after="{lookback_days} days ago",useRegex=trueto count newly added markers in the period. - Use
diff_searchwithpattern="TODO|HACK|FIXME",removed=true,after="{lookback_days} days ago",useRegex=trueto count removed markers in the period. - Net change = added - removed. Positive = accumulating debt. Negative = paying down debt.
- Use
- Measure test file ratio. For each repo:
- Use
keyword_searchwith queryrepo:^{repo}$ file:test type:path count:allto count test files. - Use
keyword_searchwith queryrepo:^{repo}$ file:\.(py|java|ts|js|go|kt|scala)$ type:path count:allto count source files (exclude test files). - Compute ratio: test files / (source files - test files). Report as percentage.
- Use
- Analyze PR size distribution. For each repo, use
ghCLI:gh pr list --repo {repo} --state merged --limit 100 --json additions,deletions,number,title,mergedAtfiltered to the lookback period.- Classify PRs: small (<50 lines), medium (50-250), large (250-1000), extra-large (>1000).
- Compute: median PR size, percentage of XL PRs, total PRs merged.
- Measure PR merge rates and review turnaround. For each repo, use
ghCLI:gh pr list --repo {repo} --state merged --limit 100 --json createdAt,mergedAt,numberfiltered to lookback period.- Compute: median time-to-merge (createdAt to mergedAt), PRs merged per week.
gh pr list --repo {repo} --state open --json createdAt,number,titleto count stale open PRs (open > 7 days).
- Check for large files or binary additions. Use
diff_searchwith pattern matching large additions (files with >500 added lines in a single commit) during the period. Flag as potential code quality concern. - Generate report. Output markdown:
## Code Quality Trends — {date}
Repos: {repo list} | Period: last {lookback_days} days
### Summary
- Total PRs merged: {N} | Median PR size: {N} lines | XL PRs (>1000 lines): {N}%
- TODO/HACK/FIXME net change: {+/-N} | Current total: {N}
- Test file ratio: {N}%
### Tech Debt Markers (TODO/HACK/FIXME)
| Repo | Current Total | Added | Removed | Net Change | Trend |
|---|---|---|---|---|---|
(Per-repo breakdown with trend arrow)
### Test Coverage Ratio
| Repo | Test Files | Source Files | Ratio | Assessment |
|---|---|---|---|---|
(Per-repo breakdown)
### PR Size Distribution
| Repo | Small (<50) | Medium (50-250) | Large (250-1K) | XL (>1K) | Median |
|---|---|---|---|---|---|
(Per-repo breakdown)
### PR Velocity
| Repo | Merged/Week | Median Time-to-Merge | Stale Open PRs |
|---|---|---|---|
(Per-repo breakdown)
### Flags
(Any concerning signals: growing debt, shrinking test ratio, many XL PRs, stale PRs)- Post to
#team-digestschannel if configured, never to a primary team channel. - Terminate. Report is complete when all repos have all metrics computed.
Design Principles
- Team-level only. Aggregate to team level — it is the right granularity for a periodic digest. Individual-level detail (PRs per person, TODOs per author) is too noisy for a team report.
- Deterministic math first, LLM narrates only. All counts, ratios, and distributions must be computed from actual search results and PR data. The LLM writes prose around the numbers but never invents counts or estimates ratios.
- Pair metrics with counter-metrics. Never report PR velocity without PR size. Fast merges on huge PRs may indicate insufficient review. High test ratio without TODO trends misses the full picture.
Golden Rules
- Count, don't estimate. Every number comes from a Sourcegraph search or gh CLI result. Never say "approximately" — run the query and report the actual count.
- Net change matters more than absolute count. 500 TODOs is not inherently bad; +50 TODOs this month is a trend worth flagging.
- PR sizes are lines changed (additions + deletions), not file count.
- Use regex for debt markers.
TODO|HACK|FIXMEmust be searched withuseRegex=trueto catch all variants. - Filter PRs to the lookback window. Don't include PRs merged before the reporting period.
- Check ALL repos, not a sample.
Anti-Rationalization Counter-Table
| Excuse | Reality |
| "I estimated the TODO count from a sample of files." | Run the actual keyword_search. Sampling gives wrong numbers. |
| "PR sizes aren't available so I skipped that section." | The gh CLI returns additions and deletions for every PR. Compute the sum. |
| "Test ratio is hard to measure so I described it qualitatively." | Count test files. Count source files. Divide. It's arithmetic, not judgment. |
| "The repo has too many PRs to analyze all of them." | Use --limit 100 and note the sample size. 100 PRs is a representative sample for monthly trends. |
| "I listed the metrics but didn't flag any concerns." | The Flags section exists to surface concerning trends. If debt is growing or test ratio is shrinking, say so. |
Termination Labels
| Label | Meaning |
report_complete | All repos analyzed, all metrics computed, flags identified |
report_partial | Some repos analyzed but search or CLI errors prevented full coverage — noted which |
no_repos_configured | No repos specified — need config.json or user input |
api_error | Sourcegraph or GitHub API unreachable |
Self-Review Checklist
- TODO/HACK/FIXME counts come from actual Sourcegraph searches (not estimates)
- Net change computed from diff_search added vs removed counts
- Test file ratio computed from actual file counts
- PR size distribution computed from gh CLI data with additions+deletions
- PR velocity includes time-to-merge AND stale open PR count
- All configured repos were analyzed
- Flags section surfaces any concerning trends
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

