Menú
Use when asked to evaluate, audit, or assess codebase health — runs git-based analyses for churn, contributors, bug hotspots, velocity, and firefighting, then synthesizes a structured report
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Conduct a thorough multi-model code review in parallel, apply only high-confidence behavior-preserving fixes, and verify the result. Use when the user explicitly asks for a full, deep, or thorough review-and-fix pass over a worktree, branch, commit range, diff, or named files; ordinary read-only review requests should not trigger it.
Use when a branch has fallen behind a fast-moving main and needs main brought in, or when asked to "merge/rebase main into my branch", "update my branch with main", "fix the merge conflicts", or "resolve conflicts" on a feature branch. Covers locating/creating the branch's worktree, choosing merge vs rebase by PR state, and resolving conflicts.
Perform a thorough read-only multi-model code review with dedicated agents for standards, spec compliance, soundness, tests, performance, and architecture. Use when the user asks to review a branch, PR, commit range, worktree, diff, or code changes without requesting edits or fixes.
Review the recently changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality only — it does not hunt for bugs. Use when the user asks to simplify, refine, tidy, clean up, or improve the readability/maintainability of code they just wrote or changed.
Use when implementing any feature or bugfix, before writing implementation code
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
| name | evaluate-codebase |
| description | Use when asked to evaluate, audit, or assess codebase health — runs git-based analyses for churn, contributors, bug hotspots, velocity, and firefighting, then synthesizes a structured report |
Run 5 git-based analyses in parallel, then synthesize into a structured report.
Before running analyses, sample recent commits to detect the commit message format. This determines how to identify fix commits and filter noise.
git log --oneline -50
Detection rules:
type(scope): description): If >60% of sampled messages match ^(feat|fix|chore|refactor|build|test|ci|perf|style|docs?|revert)\b, the repo uses conventional commits.Based on the result, set two strategies used in analyses below:
| Conventional Commits | Freeform | |
|---|---|---|
| Fix grep | --grep="^fix" (precise — targets only fix-type commits) | --grep="fix|bug|broken" with -i -E (broad — necessary when messages are unstructured) |
| Release noise filter | --invert-grep --grep="^chore.*release" | --invert-grep --grep="release|bump version" (adapt to observed patterns) |
| Firefighting regex | '^[a-f0-9]+ (revert|hotfix|emergency|rollback)|^[a-f0-9]+ \w+\(\w+\): revert' | 'revert|hotfix|emergency|rollback' |
Run ALL 5 analyses in parallel using Bash, applying the detected strategy.
Most frequently modified files, excluding noise (bots, lock files, changelogs, generated files). Use the release noise filter from Step 0:
git log --format=format: --name-only --since="1 year ago" \
${RELEASE_NOISE_FILTER} \
| grep -vE '(^$|\.lock$|CHANGELOG|package-lock|\.min\.)' \
| sort | uniq -c | sort -nr | head -20
All-time and last 6 months, excluding bots:
echo "=== ALL TIME ===" && \
git log --format='%aN' | grep -vE '\[bot\]$' | sort | uniq -c | sort -nr && \
echo "=== LAST 6 MONTHS ===" && \
git log --format='%aN' --since="6 months ago" | grep -vE '\[bot\]$' | sort | uniq -c | sort -nr
Files with highest ratio of fix-commits to total commits (minimum 5 changes). Use the fix grep from Step 0. Fix-ratio is more accurate than raw counts because it filters out registry files that are "along for the ride" in every commit.
join -t$'\t' \
<(git log ${FIX_GREP} --name-only --format='' --since="1 year ago" \
| grep -vE '(^$|\.lock$|CHANGELOG)' | sort | uniq -c \
| awk '{print $2"\t"$1}' | sort) \
<(git log --name-only --format='' --since="1 year ago" \
| grep -vE '(^$|\.lock$|CHANGELOG)' | sort | uniq -c \
| awk '{print $2"\t"$1}' | sort) \
| awk -F'\t' '$2 >= 5 {printf "%.0f%%\t%s/%s\t%s\n", ($2/$3)*100, $2, $3, $1}' \
| sort -nr | head -20
Why fix-ratio matters: A file with 5 fix commits out of 6 total (83%) is genuinely problematic. A file with 20 fix mentions out of 40 total (50%) in a freeform repo may just be a registry touched by many commits — note this caveat in the report when using the broad grep.
git log --format='%ad' --date=format:'%Y-%m' \
--invert-grep --grep='\[bot\]' \
| sort | uniq -c
Reverts, hotfixes, and emergency commits. Use the firefighting regex from Step 0:
git log --oneline --since="1 year ago" | grep -iE ${FIREFIGHTING_REGEX}
After collecting results, produce a report with these sections:
echo "First commit: $(git log --reverse --format='%ai' | head -1)" && echo "Total commits: $(git rev-list --count HEAD)" && echo "Contributors: $(git log --format='%aN' | grep -vE '\[bot\]$' | sort -u | wc -l)" && echo "Files tracked: $(git ls-files | wc -l)"__init__.py, sources.yml, or other registry that gets touched by every feature, note it as "high churn / low intrinsic risk" rather than flagging it as a bug hotspot