메뉴
Reviews PR changes against the broader codebase to find inconsistencies, missed propagation, and stale references beyond the diff. Replicates senior reviewer codebase knowledge. Activates when reviewing PRs, checking consistency, or when changes touch shared entities across multiple files.
Autonomously drives ONE feature end-to-end — understand, implement, review-and-fix, and open a right-sized PR — inside its own worktree. Runs as the main loop of a background feature agent (launched by /hv:launch-agents, or directly via `claude --bg "/hv:build-feature ..."` for a single feature). Accepts a spec-file path, inline JSON, a plain-text task, or `<spec> <featurename>`.
Turn a GitHub issue, spec file, or free-text request into a design and the right-sized plan to build it. Judges the epic's total weight and decides whether to keep it as a single PR (small/cohesive work) or decompose it into independent, parallel-executable features for a fleet of agents (large work or separable risky cores) — it does not split by default. Use this first, before launching any work. Free to propose a better architecture than the current code; sizes by risk and independence. Outputs a feature manifest (one or more features) that /hv:launch-agents consumes.
Watch one feature's PR in the background and auto-clean its agent, worktree, and branch once it merges. Use after a feature's PR is open to wire hands-off cleanup on merge (typically called by /hv:build-feature as its final step). It polls GitHub with exponential backoff and only triggers cleanup — the actual removal is done by /hv:clean-agents.
Prepare a parallel launch from a /hv:plan-features manifest — validate it, write a self-contained spec file per feature, and emit ready-to-paste `claude --bg` commands grouped into dependency waves for the human to run. Use after design when you're ready to run features in parallel. Does not spawn sessions itself (a session launching sessions is unsupported); it produces the exact launch commands. Each launched agent auto-isolates in its own git worktree.
Code quality standards for reviewing code changes. Activated when reviewing PRs, implementing features, or discussing code quality. Triggers on requests to "review code", "check quality", "improve code", or "refactor".
Security review checklist for code changes. Automatically activates when reviewing security-sensitive code, authentication, authorization, or data handling. Use when user asks to "check security", "review for vulnerabilities", "audit code", or when changes touch auth, crypto, user input, or API endpoints.
| name | reviewing-codebase-consistency |
| description | Reviews PR changes against the broader codebase to find inconsistencies, missed propagation, and stale references beyond the diff. Replicates senior reviewer codebase knowledge. Activates when reviewing PRs, checking consistency, or when changes touch shared entities across multiple files. |
| allowed-tools | Read, Grep, Glob, Bash |
| metadata | {"author":"ken2403","version":"1.0.0"} |
A senior reviewer has the full codebase in their head. When they read a diff, they instantly know what other files should also change. This skill replicates that by building codebase context around the diff and checking for inconsistencies.
Apply on every PR review. The value scales with PR size and cross-cutting concerns.
Copy this checklist and track progress:
Codebase Consistency Review:
- [ ] Step 1: Build codebase context
- [ ] Step 2: Run local build
- [ ] Step 3: Trace change propagation
- [ ] Step 4: Check related files outside the diff
- [ ] Step 5: Verify cross-layer consistency
- [ ] Step 6: Compile findings
This is the most critical step. The usage graph is what a senior reviewer holds in their head.
Run the project's build, lint, and typecheck commands to collect concrete errors. Detect the appropriate commands from the project structure (Makefile, package.json, pyproject.toml, Cargo.toml, go.mod, etc.).
Build errors provide a mechanical safety net that catches every compile-time inconsistency that code reading alone might miss. Categorize errors by file and type.
For each changed entity from Step 1, verify the change has propagated to ALL dependent code:
For detailed propagation paths by change type, see references/propagation-paths.md.
For each candidate file identified in Step 1 (in usage graph but not in diff):
Also check for files that are in the diff but only partially updated — for example, a variable was renamed but string literals or form field references using the old name were not.
Check that changes are consistent across all layers of the application:
Output structured findings:
PR_INTENT: [one-line summary of what the PR is trying to accomplish]
CHANGED_ENTITIES: [list of entities modified by the diff]
BUILD_ERRORS: [categorized list or "none"]
MISSED_FILES: [file:line list with what needs updating, or "none"]
PARTIAL_UPDATES: [file:line list with what was missed, or "none"]
CROSS_LAYER_ISSUES: [list or "none"]
MIGRATION_ORDERING: [conflicts or "none"]
For each finding: