Code review by several models at once — Claude sub-agents, OpenAI Codex, and a cheap third reviewer via OpenCode — reconciled into one report. Reviews whatever is named: a diff, a branch, specific files, one function, a legacy module, a whole repo. Use for any review request, a second or third opinion, a cross-check before a PR, or "code-review", "multi", "consensus review".
Perform thorough code reviews with security, performance, and maintainability analysis. Use when user asks to review code, check for bugs, or audit a codebase.
Perform code review. Use for: (1) '/code-review' to review the current branch changes, (2) '/code-review PR #123' to review a specific PR, (3) '/code-review staged' to review staged changes, (4) requests such as 'review this code' or 'please review'.
Adversarially verified multi-dimensional review of a code diff. Runs independent reviewers across language, architecture, QA, devops, security and technical-lead, then makes two skeptics try to refute every blocker and warning before it reaches you. Use after implementing a change, before opening an MR, or when a diff is high-stakes enough that false positives would waste real time.
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/PRD 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 the changed code in the working tree against project conventions and common bug patterns. Use when the user asks for a code review, before committing, or before opening a PR.
Use when the user wants to review a file for bugs, antipatterns, or quality issues. Triggers on "review", "check for issues", "look for problems", "audit", "before I ship".
Review pull requests in the SAP Testing Automation Framework. Use when reviewing a diff, a pull request, or staged changes touching platform code, Ansible roles and playbooks, custom modules, or the shell CLI. Reviews for correctness, reliability, security, Azure/SAP domain rules, performance, test coverage, and maintainability — in that priority order. Finds defects that let a validation report success without validating, accept a field and then discard it before it acts, break an object's stated contract, or leave one half of the SUSE/RHEL or HANA topology matrix unhandled.
Review a GitHub PR for bugs, security, performance, and code quality. Use when asked to review a PR or give pull request feedback. Don't use for local uncommitted changes, creating PRs, or merging.
Review code changes for correctness, conventions, performance, security, and test coverage. Use for: PR review, regression-risk analysis, Biome/TypeScript convention checks, API auth and validation review, block/tool contract audits, and severity-ordered findings.
Review diffs, pull requests, commits, patches, or source files for correctness, baseline security, performance, maintainability, tests, and integration risk. Use for ordinary read-only review, edge-case audits, PR preflight, and reviewer simulation; use audit-code-security when security is the primary objective, and harden-code-paths to fix confirmed failure modes.
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\".
Perform structured code reviews focusing on correctness, readability, security, and maintainability. Use this skill when reviewing pull requests, evaluating code changes, or establishing review standards for a team.
Review changed code (session, current branch, or colleague's branch) for principle violations, reinvented wheels, and dead code. Trigger after coding, before merge, or for 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.