Scope of Use and Preparation
This skill can be installed standalone; the necessary methods are all in this file and it does not depend on the author's local machine or other skills. First read the target project specifications, confirm the target repository/workspace, version, user results, and permitted changes; the reference repository is read-only. When there are no project rules, read the actual README, scripts, and source code to derive the entry points.
Execute with currently available and authorized tools: if an independent agent is lacking, use a new session/manual review or self-check from separate perspectives, and note the actual review method; if a browser/real API is lacking, complete the executable parts and hand off the uncovered acceptance items, and do not pass off as independent review, GUI, or real service success. The project's original runtime environment is still required; do not bind to a model vendor or specific plugin.
For complex tasks, you may use assets/task-record.md to save necessary facts; for simple tasks, record results directly and do not mechanically add process.
The goal is to discover the real defects in the changes, avoid the author self-certifying, and also avoid accepting the reviewer's inferences wholesale.
Fact Package for the Independent Reviewer
Use an independent agent when the current host and task authorization permit delegation. Prioritize passing necessary facts and avoid inheriting the author's full reasoning and "why it is definitely correct" conclusions.
Common inputs include: target repository and workspace, project rules, target SHA/diff, original task, user acceptance conditions, necessary raw reproduction materials, and raw results of checks already run. Mark the reference repository as read-only. Discovered issues must not be directly mixed into the main workspace by the reviewer.
The reviewer's responsibility is read-only review and performing necessary verification in an isolated location; report to the author for unified verification, adjudication, and modification. Clearly allow the temporary write location, executable operations, and end conditions, and do not let the review task expand into redoing the entire project.
Divide Work by Failure Mode
Two tracks are usually enough to start: one track checks the original requirements and the user's actual entry points, and the other checks change impact, errors/cancellation/recovery/resource cleanup. Add specialized perspectives when platform, protocol, or data migration has additional risks, and do not repeat checks by a fixed number of people.
Independent review does not aim to "find a full quota of bugs." It may report that no confirmed issues were found, while stating which critical paths were checked and which lack evidence. There is no need to mechanically add praise just to appear balanced.
When delegation is unavailable or current rules do not permit it, continue with different review perspectives and state the limitations; do not report a single agent's multiple rounds of thinking as multiple independent reviewers.
Findings Protocol
Each finding provides:
- File and location, applicable version or diff.
- Trigger conditions and user-visible consequences.
- Producer-to-consumer or call path.
- Measured evidence, complete code path evidence, or proof not yet completed.
- Relationship to this change: new regression, pre-existing issue blocking the original goal, or unrelated old issue.
Distinguish confirmed, highly suspicious, and pending confirmation, and note whether it is measured or code-derived. Separate theoretical possibilities, style preferences, and actual bugs; do not list something as a blocker merely because you "dislike the writing style."
Author Adjudication and Re-review
Verify key findings one by one, recording adoption, rejection, or pending confirmation and the reasons. Merge duplicate findings; a majority vote cannot replace evidence. Fix confirmed issues relevant to the task; record unrelated old issues as follow-ups, and do not expand the submission in passing.
After fixing, run the corresponding failed experiments and affected acceptance checks; new regressions need to be handled. Review only the actual new changes and related paths, and do not unconditionally rerun all reviews. When the scope or resources change materially, report unresolved items rather than looping indefinitely.
Delivery
First report the valid findings that affect task completion, then give the verdict, verification, and uncovered scope. When there are no confirmed findings, still define the review scope and do not claim to "guarantee no bugs."
Review conclusions are bound to a specific version. Changes caused by subsequent synchronization, merging, or conflict resolution require corresponding re-review; a pass for an old SHA cannot be automatically transferred to the new state.