code-review

The environment contract is the installed tree's references/requirements.json, stitched by the distribution build when skills update installed it: it lists every external tool this skill needs (git, glab, uv/uvx) with its check command, a copy-ready install command, and the channel source_revision. In the first session, before any other work, run python3 scripts/check_environment.py from the skill directory and show its output: the runner prints one OK/FAIL line per tool and, for every failure, the exact install command to hand to the user. The runner installs nothing and makes no network call; never install a tool automatically, print the command instead. The runtime is the Python 3.12+ application in apps/reviewmatic, run ephemerally from Git with uvx; it is not published to npm or PyPI and needs no uv tool install. Select the same source channel as the skill: an exact vX.Y.Z release tag for stable, or the moving dev branch for development. Read source_revision from references/requirements.json and set REVIEWMATIC_FROM='git+https://github.com/kisev/skills.git@<sha>#subdirectory=apps/reviewmatic' once — a session never resolves the tip with git ls-remote. An archive installed before this contract carries the legacy references/runtime-pin.json instead; when references/requirements.json is absent, read source_revision there. Only when neither file is present (a development checkout without them) resolve the dev tip once with git ls-remote https://github.com/kisev/skills.git refs/heads/dev and pin that exact commit the same way. Treat every reviewmatic found on PATH as a foreign, possibly outdated binary and ignore it; the only runtime is the pinned uvx --from "$REVIEWMATIC_FROM" install, and a PATH hit is never diagnosed or inspected as if it were part of this review. Run every CLI command, including returned continuation actions, as uvx --from "$REVIEWMATIC_FROM" reviewmatic ..., and verify the pin right after the first invocation with reviewmatic runtime-info: compare the printed resolved commit to the pinned SHA in REVIEWMATIC_FROM (unknown or a mismatch means a stale uvx cache or an unpinned install — re-pin with the exact @<sha> and add --refresh-package reviewmatic before continuing). Open the session's first response with the version banner, assembled entirely locally: the skill version from references/requirements.json (version), the reviewmatic version and resolved install commit from reviewmatic runtime-info, and the glab --version line — no network call belongs to the banner.

Drive a remote-MR review through the one-process reviewmatic run path. At its start the run asks one poll — the critic composition and the engine of every critic (a subagent on the current session's model or the mechanical ocr CLI): present the printed fenced poll block verbatim, collect the user's choice with the host's native interactive question tool (recommended composition / single model subagent / subagent+OCR / custom), fill the selection template from that answer yourself, and run the printed command — the user never writes JSON. Ground the critic pool in the host's agent inventory (agents/*.md in the harness-global and project config directories, and the agent key of the global and project opencode.json; only agents the user configured — never the bundled agent assets of installed packages or plugins under node_modules/, which deploy only through configure agent), propose multi-critic options only when candidate agents carry distinct models or engines, and never propose two critics on the same single model — that is not independent review. The step-by-step start-review/record-* flow remains supported as the explicitly marked repair path. references/local-review.md owns the separate local-WIP mode.

Apply references/simplification-criteria.md for the optional simplification criteria.

Apply references/context-package.md for the context-package template and verification rules.

The normal tail is decision → shared render → edit the generated prose file → reviewmatic record-prose → resume and finalize. Head drift retains authorship and asks for a fresh reviewmatic record-delta verification of changes and affected conclusions. Original checks remain historical; never replace their digests or treat a mapped source position as proof of a finding's truth.