A single reviewer has blind spots — that is the entire premise of this skill. It structures a review into independent lenses that each look for a different failure mode, then makes every candidate finding survive an adversarial "try to refute this" pass before it's allowed into the report. Findings that don't survive verification are dropped, not softened.
Do not use this for the mechanics of fetching a GitHub PR's diff or finding a
target repo's own rule files — that's soia-dev-github-ops's Pre-Merge Rule
Review. This skill is the review methodology that procedure calls into once
it has a diff in hand; it also works standalone on a local diff or a skill
package with no GitHub involvement at all.
Customer-readable explanation
What this skill can do
| Customer wants | Skill will do | Customer can see |
|---|---|---|
| Review a code change from multiple angles without missing anything | Split into independent perspectives and go through them one by one (in parallel when possible); each candidate finding then goes through a round of adversarial re-review, keeping only those that withstand rebuttal | Tiered findings list (blocking/should fix/informational) + evidence level for each item |
| Review a skill package (SKILL.md/scripts/references) | Switch to a set of perspectives specific to skill packages (host independence, security gate completeness, cross-file description consistency, etc.) | Same as above |
| Only wants to know which aspects were reviewed and whether anything was missed | The report explicitly lists the parts that were "checked and found fine", not just problems | Coverage scope explanation |
How customers use it
Other recognizable phrasings include "recheck from a few perspectives" and "review this skill package"; this skill only reports findings and does not perform edits, merges, or publishing.
- Specify the review target: local uncommitted changes, a diff text already in hand, or a skill directory path (such as
skills/<name>/）。 - If the target type is unclear (code change vs skill package vs both), ask first before proceeding; do not guess.
- If there are requirements about strictness (for example "be stricter" or "this time be quick"), adjust the number of perspectives and review rounds accordingly; the default is the basic perspective set listed below.
- The report contains only findings that are "confirmed to hold after re-review"; it does not automatically change code, commit, merge, or publish—those are the user's own next steps.
Dependencies and installation
Installation (recommended: install the entire domain plugin to install all skills in this repository at once):
claude plugin marketplace add soia-team/soia-open-skills
claude plugin install soia-dev@soia
When you only want this one skill, you can use the npx route. Note that the skill will land in the shared source of truth ~/.agents/skills; if the plugin is also installed, the same skill will have two indexes and they will drift separately, so it is recommended to choose one of the two:
npx skills add soia-team/soia-open-dev-skills -g -a '*' -s soia-dev-review-panel -y
Hard dependency on soia-dev-coding-protocol: the "test coverage and anti-patterns" perspective of this skill directly reuses its Anti-Fake-Fix Gate and pre-commit self-review checklist, without maintaining a second copy. Installing this skill will automatically bring in this dependency.
This skill does not require private configuration.
WorkBuddy 's loading unit is role-based experts rather than plugins,npx skills add -a '*' cannot cover it, and it needs to be installed separately, see docs/install/workbuddy.md。
Private information and intermediate data
This skill does not persist any data and does not require credentials, cookies, or API keys. Review materials (diff content, skill directory content) are used only in the current conversation/subtask context and are not written to any files, logs, or third-party services; if used in combination with soia-dev-github-ops , the credentials and network request boundaries are handled by that skill and are outside the scope of this skill.
Logs and completion receipt
完成：<一句话说明审了什么、结论是什么>。
发现清单：<按阻断/应改/提示分档，每条给位置和证据等级>
覆盖范围：<用了哪些视角，核实过没问题的部分>
决定权：<交还使用者——建议合并/建议先改/建议不合并，不代为执行>
Step 0 — Determine target type and perspective group
- The target is a code diff (local
git diff, a diff text already in someone else's hands,soia-dev-github-opsa PR diff handed over) → use the "code perspective group". - The target is a skill package (
skills/<name>/directory, or the changes mainly fall in some skill'sSKILL.md/scripts/references) → use the "skill package perspective group"; if the skill package also containsscripts/*.pyand similar code, both groups must be used. - If the target type or scope boundary is uncertain, ask first, do not guess.
Step 1 — Perspective checklist
Each perspective executes independently and reads the original material independently, without sharing the previous perspective's conclusions—this avoids anchoring, which is the core value of multi-perspective review; skipping this point means spending the cost but not getting the benefit.
Code perspective group
| Perspective | Focus points |
|---|---|
| Correctness and self-verification | Whether the change actually does what it claims—go read the original text of the changed files to verify, not just diff fragments (a diff only shows changed lines + a little context, making it easy to miss the full signature/branch) |
| Security | Whether external input (URL/path/user data) is validated; whether there are hardcoded keys/tokens; whether credentials or private data have leaked into logs or commit history |
| Test coverage and anti-patterns | Apply the soia-dev-coding-protocol 's Anti-Fake-Fix Gate item by item: whether there are tests but the assertions are too loose ("it runs without errors" does not count as verification); whether numerical claims in the description ("N tests passed" "processed M records") have been independently reproduced, do not directly accept them |
| Scope and consistency | Whether the change exceeds the scope claimed in the title/description; whether the documentation (README/SKILL.md/CHANGELOG) has been synchronized with the behavior change; whether the dependency direction is reversed |
Skill package perspective group
| Perspective | Focus points |
|---|---|
| Command/interface correctness | Whether each command appearing in the skill body (gh CLI, script calls, etc.) is actually syntactically correct—do not rely on experience to judge whether field names and parameters exist. Verify only in side-effect-free, login-free ways (--help、--dry-run, pure query calls); if the command itself requires credentials or has side effects (create/merge/delete/send/authorization change types), switch to checking parameters against official documentation, do not actually execute it—this hard restriction takes priority over the "no credentials required" statement in the "private information and intermediate data" section, and is its concrete implementation, not an exception |
| Security gate completeness | Whether high-impact operations (delete, overwrite, send, publish, authorization change) all have corresponding explicit confirmation requirements; whether grant-type operations have symmetric verify/revoke verification steps |
| Host independence | Whether there is dependence on a specific AI CLI's proprietary tools (such as Claude Code's computer/claude-in-chrome/built-in slash command); the body must be independently understandable and runnable by other hosts (Codex, Gemini CLI, etc.) |
| Consistency and synchronization | frontmatter description / agents/openai.yaml / the corresponding line in the top-level README / auto-generated table of contents, whether the descriptions of capabilities in these places are synchronized with each other;version whether it is bumped along with this change; whether the skill name collides with an existing skill (especially across repositories)—on this machine ~/.agents/.skill-lock.json is stored by name as a single key, regardless of source repository, and name collisions will overwrite each other's installed files |
When stricter review is needed, add perspectives as needed beyond the base perspectives (for example, add a "concurrency semantics" perspective for changes involving concurrency); do not force in unrelated perspectives just to make up the numbers.
Step 2 — Dispatch
If the current environment supports spawning independent subtasks (such as Claude Code's Agent/Workflow tools, or equivalent parallel mechanisms provided by other hosts), assign the selected perspectives to independent subtasks for parallel execution, giving each subtask only the instructions for its own perspective and the raw material, and do not feed it the conclusions of the other perspectives as well.
When the current environment does not support spawning subtasks, go through the perspectives one by one in order within the same context: before switching to each perspective, explicitly state "now only use the standards of perspective X, forget the conclusion from the previous perspective," write this sentence out in written form, and then continue, to prevent the perspectives from contaminating each other's judgment. The candidate findings produced by the two methods have the same format; which one to choose depends on environment capability, not on strictness.
Step 3 — Format of candidate findings
Each candidate finding has a fixed set of four elements:
- One-sentence title
- Specific location (file path + line number, or section name — do not just say "somewhere")
- Evidence level: seen (quote the original text) / inferred (give the reasoning chain) / uncertain (state it explicitly and give a verification path)
- Severity candidate: blocking (violates a hard rule / security issue / obvious bug) / should fix (not blocking but worth addressing) / note (checked and no problem, or minor observation)
Step 4 — Adversarial review (cannot be omitted)
The dispatch method follows the same degradation rules as Step 2: if independent subtasks can be spawned, spawn them; if not, do it in the same context, but first write a written switch sentence (for example, "now I am only responsible for trying to refute this finding, ignore my judgment just now as the original perspective") and then continue — the anchoring risk faced by review and the mutual contamination between perspectives in Step 2 are the same type of problem, handled by the same set of rules.
For each candidate finding rated "blocking" or "should fix," re-examine it from a different independent perspective, specifically trying to refute it:
- Go back and read the raw material itself, not the paraphrase from the previous step — paraphrase amplifies or dilutes the original information, so you must return to the source.
- Default toward "does not hold"; only judge it "holds" after it has actually been reproduced and verified.
- Check: whether the cited evidence really exists in the original text; whether the severity has been exaggerated or underestimated; whether there is a counterexample that can refute the conclusion; if during review a more accurate problem description is found (for example, the line-number citation in the original finding is off), use the corrected version, and do not discard the entire finding just because a detail is off.
- Candidate findings at the "note" level (checked and no problem) do not need adversarial review and go directly into the coverage scope description of the final report.
Only findings judged "holds" by review enter the final report.
Step 5 — Output
The final reply must include:
- One-sentence conclusion: whether this change overall is one of "recommend approval," "recommend fixing first," or "recommend rejection," placed at the very front.
- Findings list: grouped by blocking/should fix, with location, evidence level, and a brief explanation for each.
- Coverage scope: which perspectives were used, and the parts that were verified but where no problem was found (do not report only problems; let the reader know where the review boundary is).
- Decision-making authority explicitly returned: this is a review recommendation, not permission for automatic execution — this skill does not modify code, commit, merge, or publish; that is the user's own next step after reading the report.
Relationship with other skills
| Skill | Relationship |
|---|---|
soia-dev-coding-protocol |
Strong dependency. The "Test Coverage and Anti-Patterns" perspective directly reuses its Anti-Fake-Fix Gate and pre-commit self-review checklist, avoiding duplicate maintenance |
soia-dev-github-ops |
One-way dependency, with the direction opposite to the other rows in this table: its Pre-Merge Rule Review hard-depends on this skill (if it cannot be installed, it stops rather than degrading into maintaining its own checklist), and it is responsible for "pulling the PR diff + finding the target repository's own rule files," then handing the results to this skill for the Step 1-4 perspective review and adversarial re-check. This skill does not depend on it in reverse, nor does it know how to use gh CLI to pull PRs; that part is left to it |
soia-private-skills of soia-dev-code-review |
is not the open-source version of the same skill, and the two can be installed at the same time (different names, no conflict). That skill specifically serves proposal/Wave/fix governance reviews within confirmed SOIA product workspaces, binding specific models to specific dimensions across 6 dimensions based on the team's internal experience; this skill is a general methodology, contains no product/team-specific information, and does not assume a particular model division of labor. vault,soia-open-dev-skills、soia-private-skills reviews with ordinary repositories use this skill; confirmed SOIA product governance reviews use that one |