Multi-agent review of the local git diff. Spawns parallel agents covering bugs+security, CLAUDE.md adherence, git history, performance, plan adherence, and quality+architecture; tiers findings by confidence (Critical/Warning/Suggestion/Nit) and drops only auto-zeroed false positives; writes REVIEW.md. Also has a whole-tree mode (`/code-review tree [glob]`, or wording like 「審核架構／有沒有重複」) that audits the current source for duplication and missing abstractions instead of a diff. Use when the user says "review my changes", "review this branch", "code review", "審核架構", or invokes /code-review. Supersedes the built-in /code-review in repos using dev-skills — invoke only this one.
Performs a comprehensive, multi-step code review of pull requests or local code changes, using iterative refinement (generation, critique, synthesis) to ensure high-quality, actionable feedback. Use when you need to review code changes thoroughly.
Perform a mandatory scoped code review for the code changed in the current task. Use when Codex has implemented or modified code and must review the touched scope for requirement compliance, existing style consistency, stability, scalability, efficiency, security, integration with real code paths, compatibility, dry-run behavior, structural clarity, helper boundaries, fallback justification, and silent error masking; a user request to use this skill counts as explicit permission to use 1-3 read-only review subagents for broad changed scopes; fix any discovered issue immediately unless it requires a user decision or integration with code that does not exist yet.
Review code changes either from the local working tree/current branch or from a GitLab merge request. Use when the user asks for a code review, MR review, branch review, review of local/staged changes, or wants findings that can optionally be posted back to GitLab via glab.
Automated code review for pull requests using parallel analysis with confidence-based scoring to filter false positives. Use when the user asks to review a PR, review code changes, or run a code review.
Automatically use before committing a substantial change; when work on an experiment is finished and the question is whether it answered the hypothesis it stated and whether it is well built; when the owner asks whether something is any good, is ready, or can be relied on; when they ask whether a piece of work is done and they can move on to the next thing; and when they ask for a review of changes, a diff, a branch, or a pull request. Reviews on two separate axes - whether it did what was asked, and whether it is well built - and reports them apart, because reporting them together lets a pass on one hide a failure on the other. Do not use for a routine question about a single line, for a change small enough that the answer is the answer, on code still being written, or immediately after a review with no work in between.
Automatically use before committing a substantial change; when work on an experiment is finished and the question is whether it answered the hypothesis it stated and whether it is well built; when the owner asks whether something is any good, is ready, or can be relied on; when they ask whether a piece of work is done and they can move on to the next thing; and when they ask for a review of changes, a diff, a branch, or a pull request. Reviews on two separate axes - whether it did what was asked, and whether it is well built - and reports them apart, because reporting them together lets a pass on one hide a failure on the other. Do not use for a routine question about a single line, for a change small enough that the answer is the answer, on code still being written, or immediately after a review with no work in between.
Reviews code changes for bugs, security issues, performance problems, and adherence to project conventions. Use when the user asks for code review, PR review, or after significant code changes. Trigger words include review, check code, PR.
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 a proposed code change using Codex's standard review rubric. Use when asked to review a diff, PR, branch, local change set, staged changes, or any code modification for actionable correctness, security, performance, maintainability, or regression findings.
Review code changes in the Psyche Build repository for high-confidence, actionable defects. Use this skill whenever the user asks to review a working tree, staged changes, a commit, commit range, branch, pull request, patch, regression, or implementation for correctness and risk—even if they do not explicitly say "code review." It is read-only and repository-specific across TypeScript/Node, React/Vue/Ink, Tauri Rust and web bundles, Swift/iOS, protocols, generated files, packaging, CI, and release surfaces. Do not use it for an explicit vulnerability or exploit hunt; use the dedicated security-review workflow for that request.
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.
FooJiaYinSkill
