--- name: opsx-review description: Independently review one OPSX candidate in a fresh session at pause 2 or after approved fixes. Compare a fixed Git revision with its accepted proposal and record the verdict in review.md. compatibility: Requires Git, Node.js and OpenSpec 1.12.0. Uses a repository-local OpenSpec project. --- # Independent OPSX review 1. Start in a fresh reviewer session. Obtain the operator-designated base ref, committed candidate head and change ID. Resolve and record the base commit, candidate head and candidate tree with `git rev-parse`. Require the worktree at the candidate. Use Git to inspect staged, unstaged and untracked paths. If anything besides the named pause or review receipts differs from the candidate, stop and ask for a clean snapshot. A reviewer who implemented the change must hand off to a fresh session. 2. From the candidate worktree root, run `node /scripts/openspec.mjs status --change --json`. Resolve the sibling `opsx` directory from this skill's location. Require a repo-local planning root matching this worktree. Read the repo rules, brief, `pause1.md`, `pause2.md` and `pauseR.md` if present. Read the change artifacts from the candidate and verify the [proposal snapshot](../opsx/references/plan-snapshot.md) against the accepted receipt. If the candidate or accepted proposal is ambiguous, record the missing input and stop. Resolve the comparison point with `git merge-base ` and review `git diff `. 3. Resolve and verify the accepted [project agreements](../opsx/references/project-rules.md) from the candidate worktree. Review the diff against those rules, repository standards and the accepted proposal, deltas and task outcomes. Look for behavior regressions, uncovered conditions and scope creep. Add a security pass when the change touches input, authentication, permissions, network, storage, devices or another trust boundary. Trace the actual risky path and distinguish verified findings from unverified questions. 4. Run `node /scripts/openspec.mjs validate --type change --strict` against the candidate. Use project checks only if authorized and safe in this worktree. Read the executor's evidence from `pause2.md` and, after fixes, the revised subject in `pauseR.md`. Verify that the subject and environment of each required check apply to the candidate. Label the checks you ran separately from evidence supplied by the executor. Missing required evidence blocks acceptance. Confirm the candidate and worktree status again before writing the verdict. 5. Write or update only `review.md` in this change's `changeRoot`. Include the change ID, full base, merge-base, head and tree SHAs, relevant scope, standards and spec results, security applicability, and checks or evidence with their limits. For each actionable finding, include severity, file and line, trigger, observed or plausible effect, and the requirement it violates. When revisiting after fixes, account for prior findings in the new verdict. 6. End the review with one verdict. **Accepted** requires a reviewed candidate, resolved findings and applicable passing evidence. **Findings** means changes or an operator decision are needed. **Blocked** means the candidate or required evidence is missing or stale. Report the receipt path and stop. The operator decides the next stage.