사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/helderberto/agent-skills --skill code-review시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Review Pull Request
Mode: $ARGUMENTS — BUGS, SECURITY, or PERFORMANCE narrows the review to that axis; otherwise apply all.
Approval standard
Approve when the change definitely improves overall code health, even if it isn't perfect. Don't block a change because it isn't how you would have written it. If it improves the codebase and follows its conventions, approve.
If the change is too large to review well (~1000+ lines), asking the author to split it is a valid outcome. Suggest a strategy: stack (small change, next one based on it), by file group, horizontal (shared code first, then consumers), or vertical (one end-to-end slice per PR).
Review criteria
Review every changed file, not just the latest commit.
- Correctness: logic bugs, off-by-ones, race conditions, unhandled states, missing error paths
- Readability: functions > 50 lines, nesting > 2 levels, dead code, unused imports
- Security: exposed secrets, unvalidated external data
- Type safety & immutability:
anyor unjustified assertions; in-place mutation of shared data - Patterns: consistent with codebase conventions, no reinvented wheels
- Performance: unnecessary re-renders, O(n²) where O(n) works
- Code smells: match the diff against the baseline in smells.md — always judgement calls; the repo's documented style overrides the baseline
- Dependency upgrades (manifest/lockfile in the diff): one dependency per change — a bulk bump that breaks hides which package did it; verify against the changelog, not the version number; review the lockfile diff (one direct bump pulls dozens of transitive changes); flag hand-edited lockfiles
Output
Group by severity, file:line on every finding, a suggested fix for every Critical:
- Critical — must fix before merge (bugs, vulnerabilities)
- Suggestions — improvements worth considering
- Nit — minor and optional; label true nitpicks as Nit rather than dropping or inflating them
- FYI — informational
- Positives — good patterns to call out
One structural problem and ten nits: the structural problem is the review — lead with it. Close with the verdict against the approval standard.
