Review the current diff against path-scoped rules (secrets, RLS/tenant scoping, Stripe webhook verification, input validation, scope), flag changed code lacking tests, and run a quick security pass. Reports findings; nothing auto-fixed without approval.
Review code changes (diffs, PRs, patches, commit ranges) and provide structured, actionable feedback on correctness, security, maintainability, and test coverage. Use this whenever the user asks for a code review, requests feedback on a patch/PR/commit, wants an assessment of changes before merging, or asks "what's wrong with this change" — even if they don't say the words "code review." This is for code changes specifically, not prose documents or general writing.
Review code changes for a list of commits using two parallel AI reviewers (Claude and OpenAI Codex), then combine and fact-check findings into a single verdict. TRIGGER when: user asks to review commits, review changes, or passes commit hashes/ranges for review. SKIP: general code questions not tied to specific commits.
Use when the user asks for a full review of a change, pull request, or merge request against the personal checklist, covering design, tests, performance, security, and correctness. Also use when the user asks to read, address, answer, or reply to reviewer comments or threads, or to prepare a plan from reviewer feedback, on any platform, including GitLab merge requests through glab: MR discussions, unresolved threads, suggestion blocks, glab auth.
이미 작성된 코드나 변경분(diff, PR, 브랜치)을 검토할 때 사용한다. "이 PR 봐줘", "이 코드 리뷰해줘", "머지해도 되나", "이 변경 위험한가" 같은 요청에 트리거된다. 리뷰 범위 확정 → 위험도 분류 → 근거 있는 지적 → 보고 형식까지의 절차를 다루며, Java/Spring 코드일 경우 references/spring.md 체크리스트를 함께 적용한다. 새 코드를 작성하는 것이 목적이면 java-spring-backend를, 이미 발생한 버그의 원인을 찾는 것이 목적이면 debugging을 쓴다.
Expert in conducting thorough code reviews for Python projects using GitHub MCP, covering test coverage, security practices, PEP 8 compliance, and code organization. Use when reviewing code or PRs.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo''s documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Review code files against project standards. Use when reviewing one or more code files, a module, or changed files; coupled files are reviewed together in one worker, and every file gets its own review file.
Review changed code for architecture compliance, security vulnerabilities, test coverage, and code quality. Enforces Hexagonal Architecture for backend and MVVM for frontend. Detects test gaps and runs tests when possible. Use when reviewing a PR, branch diff, or staged changes.
Review a diff along Standards plus code-smell and Spec plus ticket axes. Use automatically as the mandatory total closing gate after run-delivery finishes all implement tickets, or standalone for any supplied Git range, staged diff, working-tree diff, patch file, or diff text.
Use when code changed and a meaningful diff is ready; fresh eyes should catch requirement gaps, regressions, or risky design mistakes before handoff or success claims. Common triggers: review, nakijken, pull request, code review, fresh eyes, start reviewing, review deze wijziging, check de wijziging, review changes, second look, bekijk de diff, controleer de code, code check, diff review, PR review.
Use when code changed and a meaningful diff is ready; fresh eyes should catch requirement gaps, regressions, or risky design mistakes before handoff or success claims.
Review code changes for bugs, security vulnerabilities, performance issues, and maintainability. Use when asked to review code, a PR, a diff, or recent changes with Opus-level thoroughness.
Critical code-quality review of staged changes (or specified files). Catches the classes of issues that pass tests but bite later — bad naming, hidden complexity, missing edge cases, weak test coverage, performance traps. Use before /safe-commit, or standalone when reviewing your own diff before pushing for human PR review.
A folder with a SKILL.md file: a name, a description of when to use it, and instructions. Claude loads a skill only when the task matches its description.
How do I use one I find here?
Copy the folder into your project's .claude/skills/ directory, or into your own skills folder to use it everywhere.
What do the warnings mean?
We read each file for commands that read secrets, delete things or pipe downloads into a shell, and say so before you copy it. No warning is not a promise that a file is safe.
Which skills worked for people?
Open a skill to see its discussion. Reports from people and their agents are coming.