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 description
What this skill can do
| Customer wants | Skill will do | Customer can see |
|---|---|---|
| Review a code change from multiple angles without missing anything | Break it into independent perspectives and go through them one by one (in parallel where 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/hint) + evidence level for each item |
| Review a skill package (SKILL.md/scripts/references) | Switch to a set of perspectives specific to skill packages (host-agnosticism, 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, no issues", not just the problems | Coverage scope description |
How customers use it
- Specify the review target: local uncommitted changes, a diff text already in hand, or a skill directory path (e.g.
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 (e.g. "be stricter" "this time be fast"), adjust the number of perspectives and review rounds accordingly; the default is the base 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
Install this skill (single skill):
npx skills add soia-team/soia-open-skills -g -a '*' -s soia-dev-review-panel -y
Hard dependency on soia-dev-coding-protocol: this skill's "test coverage and anti-patterns" perspective directly reuses its Anti-Fake-Fix Gate and pre-commit self-review checklist, rather than maintaining a second copy. Installing this skill automatically brings in this dependency.
This skill requires no private configuration.
Private information and intermediate data
This skill does not persist any data and requires no 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 file, log, or third-party service; if used in combination with soia-dev-github-ops , the credentials and network request boundaries are that skill's responsibility and are outside this skill's scope.
Logging and completion receipt
完成：<一句话说明审了什么、结论是什么>。
发现清单：<按阻断/应改/提示分档，每条给位置和证据等级>
覆盖范围：<用了哪些视角，核实过没问题的部分>
决定权：<交还使用者——建议合并/建议先改/建议不合并，不代为执行>
Step 0 — Determine target type and perspective group
- Target is a code diff (local
git diff, a diff text someone else already has,soia-dev-github-opsa PR diff handed over) → use the "code perspective group". - 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 list
Each perspective is executed independently and reads the original materials independently, without sharing the previous perspective's conclusions—this avoids anchoring, which is the core value of multi-perspective review; skipping this means spending the cost without getting the benefit.
Code-perspective group
| Perspective | Concerns |
|---|---|
| Correctness and self-verification | Does the change actually do what it claims to do—go read the original text of the changed files to verify, and do not just look at diff fragments (a diff only shows changed lines plus a small amount of context, so it is easy to miss the full signature/branch) |
| Security | Is external input (URL/path/user data) validated; are there hardcoded secrets/tokens; have credentials or private data leaked into logs or commit history |
| Test coverage and anti-patterns | Apply soia-dev-coding-protocol 's Anti-Fake-Fix Gate and check item by item: are there tests but the assertions are too loose ("it runs without errors" does not count as verification); have the numeric claims in the description ("N tests passed", "processed M records") been independently reproduced—do not simply take them at face value |
| Scope and consistency | Does the change exceed the scope claimed by the title/description; have the docs (README/SKILL.md/CHANGELOG) been kept in sync with the behavior change; is the dependency direction reversed |
Skill-package-perspective group
| Perspective | Concerns |
|---|---|
| Command/interface correctness | Is the syntax of every command appearing in the skill body (gh CLI, script invocations, etc.) actually correct—do not judge from experience whether field names and parameters exist. Verify only in side-effect-free, login-free ways (--help、--dry-run, pure query-type calls); if the command itself requires credentials or has side effects (create/merge/delete/send/authorization-change types), switch to checking the parameters against the official documentation and do not actually execute it—this hard restriction takes precedence over the "no credentials needed" statement in the "private information and intermediate data" section, and is its concrete implementation, not an exception |
| Security-gate completeness | Do all high-impact operations (delete, overwrite, send, publish, authorization change) have corresponding explicit confirmation requirements; do grant-type operations have symmetric verify/revoke verification steps |
| Host independence | Does it depend on a proprietary tool of a specific AI CLI (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 / the auto-generated table of contents—are the descriptions of capabilities in these places in sync with one another;version is it bumped along with this change; does the skill name collide 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 necessary beyond the base perspectives (for example, add a "concurrency semantics" perspective for changes involving concurrency), and do not force in irrelevant 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, and give each subtask only the instructions for its own perspective and the original materials—do not feed it the conclusions of other perspectives as well.
When the current environment does not support spawning subtasks, go through each perspective one by one in order within the same context: before switching to each perspective, explicitly state "now look only by the standards of perspective X, forget the conclusions from the previous perspective," write this sentence out in written form before continuing, to prevent the perspectives from contaminating each other's judgment. The candidate findings produced by the two approaches 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 four fixed 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 the verification path)
- Severity candidate: blocker (violates a hard rule / security issue / obvious bug) / should fix (not blocking but worth handling) / note (checked and no problem, or minor observation)
Step 4 — Adversarial review (cannot be omitted)
The dispatch method follows the same fallback 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 earlier judgment from the original perspective") before continuing — 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 at the "blocker" or "should fix" level, re-examine it from an independent perspective, specifically trying to refute it:
- Go back and read the original material itself, not the paraphrase from the previous step — paraphrase amplifies or dilutes the original information, so you must return to the source.
- By default, lean toward "does not hold"; only after actually reproducing and verifying it should you judge it "holds".
- 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 reference in the original finding is off), use the corrected version, and do not discard the whole finding just because a detail is off.
- "Note"-level candidates (checked and no problem) do not need adversarial review and go directly into the coverage scope explanation 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 "recommend approve", "recommend fix first", or "recommend reject", placed at the very front.
- Findings list: grouped by blocker / should fix, each entry giving location, evidence level, and a brief explanation.
- Coverage scope: which perspectives were used, and the parts that were verified but had no problems found (do not report only problems; let the reader know where the review boundary is).
- Explicitly return the decision to the user: this is a review recommendation, not automatic execution permission — this skill does not modify code, does not commit, does not merge, does not release; 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, without maintaining them separately |
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 and does not degrade 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, and does not 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; the two can be installed at the same time (different names, no conflict). That skill specifically serves proposal/Wave/fix governance reviews within a confirmed SOIA product workspace, 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-skills、soia-private-skills and ordinary repository reviews use this skill; confirmed SOIA product governance reviews use that one |