From buyoung-skills
Reviews git changes (commits, ranges, files, staged) with impact assessment, breaking-change detection, confidence-classified findings, and risk-weighted verdicts.
npx claudepluginhub buyoung/skills --plugin backend-skillsThis skill uses the workspace's default tool permissions.
Use this workflow to review git changes with evidence-backed findings and risk-aware verdicts.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Use this workflow to review git changes with evidence-backed findings and risk-aware verdicts.
Identify what to review from the user's request.
| User Input | Action |
|---|---|
| Commit hash provided | Use that commit |
Commit range (start~end) | Use the range (start = earliest, end = latest) |
| "리뷰해줘" / "review" with no hash | Use staged changes (git diff --cached). If nothing staged, use HEAD |
| File paths specified | Scope review to those files within the target |
Always confirm the target before proceeding:
git --no-pager show --stat <commit_hash>
# or for staged changes:
git --no-pager diff --cached --stat
Get the full diff for the review target. Refer to git_operations.md for detailed commands and fallback handling (root commits, merge commits, range stabilization).
# Single commit
git --no-pager show <commit_hash>
# Staged changes
git --no-pager diff --cached
# Commit range
git --no-pager diff <start_hash>^..<end_hash>
# File-scoped
git --no-pager show <commit_hash> -- <file_path>
Categorize each changed file and filter out noise before deep review. This prevents wasting review effort on non-reviewable content.
| Category | Examples |
|---|---|
| Source | .ts, .js, .py, .java, .go, .rs, .swift, .kt, .rb, .php, .c, .cpp |
| Test | *.test.*, *.spec.*, __tests__/*, test_*.*, *_test.* |
| Config | .json, .yaml, .toml, .env*, .*rc, config/* |
| Docs | .md, .rst, .txt, docs/* |
| Build/CI | Dockerfile*, Makefile, .github/workflows/*, *.gradle* |
| Deps | package.json, pyproject.toml, go.mod, Cargo.toml, requirements*.txt |
Skip line-by-line review for these — check consistency/integrity only:
| Noise Type | Pattern | Handling |
|---|---|---|
| Generated files | generated/, *.pb.*, *.generated.* | Inspect generation source instead |
| Lock files | package-lock.json, yarn.lock, go.sum, Cargo.lock | Verify manifest consistency only |
| Minified/bundled | *.min.js, *.bundle.js | Exclude from logic findings |
| Vendor/third-party | vendor/, third_party/ | Evaluate integration impact only |
| Mechanical renames | Status R/C with no behavioral delta | Validate paths, then deprioritize |
| Format-only changes | Whitespace/indent-only diffs | Note as low-risk, skip deep analysis |
| Files Changed | Strategy |
|---|---|
| 1–10 | Full line-by-line review |
| 11–30 | Prioritize source/config, then tests/docs |
| 30+ | Separate noise first, sample low-risk files, full-review high-risk files |
Read the full context of each reviewable file to understand the change, not just the diff. Focus on:
Identify who/what is affected by the changes. Refer to impact_detection.md for detailed techniques.
Key actions:
# Find direct callers
rg -F "symbolName(" .
# Find broader references
rg "symbolName" .
| Change Type | Breaking? |
|---|---|
| New mandatory parameter/field | Yes |
| Removed/renamed output field | Yes |
| Accepted values narrowed | Yes |
| Endpoint signature changed | Yes |
| Additive optional extension | No (usually) |
If a breaking change has normalized consumers > 0, classify at least as Critical candidate.
Assign each finding a severity and confidence level.
Immediate high risk to security, data integrity, availability, or external contracts.
Incorrect behavior, reliability degradation, or high operational cost.
Maintainability, readability, or medium-term quality concerns.
Low-impact polish and consistency.
| Factor | → Critical | → Major |
|---|---|---|
| Data risk | Loss/corruption likely, irreversible | Inconsistency possible, recoverable |
| Business logic | Core transaction/auth broken | Limited-path incorrect behavior |
| Rollback | No safe rollback path | Rollback exists and is practical |
| Observability | Incident detection critically degraded | Degraded but manageable |
| Tier | Meaning |
|---|---|
| High | Strong direct evidence; severity can be acted on directly |
| Medium | Credible but partially indirect evidence; include verification note |
| Low | Weak or indirect evidence; avoid automatic escalation, request manual verification |
A Major finding becomes a REQUEST_CHANGES candidate when ALL of:
Combine findings into a final verdict.
| Verdict | Condition |
|---|---|
| REQUEST_CHANGES | Any Critical finding |
| REQUEST_CHANGES | 3+ Major findings |
| COMMENT | 1–2 Major findings |
| COMMENT | 5+ Minor findings |
| APPROVE | Only Minor/Nit or no findings |
Use internally to validate the baseline verdict — do NOT output the score:
| Score | Adjustment |
|---|---|
| ≥ 12 with medium+ confidence | REQUEST_CHANGES |
| 6–11 | COMMENT (unless baseline already requests changes) |
| ≤ 5 and no Major+ findings | APPROVE candidate |
| Evidence Shape | Handling |
|---|---|
| High confidence + high impact | Keep or escalate severity |
| Medium confidence + medium/high impact | Keep severity, add verification note |
| Low confidence | No automatic escalation; request manual verification |
Output the review using the format in output_format.md.
Key requirements:
Highlights section when patch quality deserves recognitionrg): Consumer tracing, reference lookup, test coverage checks| File | When to Read |
|---|---|
| git_operations.md | Step 2 — for edge cases (root commits, merges, range fallbacks) |
| impact_detection.md | Step 5 — for consumer tracing and breaking change detection |
| output_format.md | Step 8 — for report structure and finding entry format |