Use when code must decide what happens on an unusual or failing path. Also use it when the user says "just handle that case", "skip it if it fails", or "is this the best way?". Compares the easy route with each alternative by what it does to the user's files, data, and output. Picks the option that fails loudly and keeps every count and exit code true. Never writes through a file that the change does not own. Not for checking finished work against the real command output (use `verify-and-review`).

Use when the user asks to review a pull request. Examples are "review PR 123", "review PRs 1, 2, 3", and "guide me through this PR". Reuses shadowclone-review locally and builds a standalone HTML with actual diffs, behavior traces, and selection comments. Saves notes into the same file. Not for fixing reviewed code (use `shadowclone-work`).

Use when Git reports conflicts during a merge, a rebase, or a cherry-pick. Also use it when the user says "fix the merge conflicts", "rebase onto main", or "the merge broke the build". Traces each side of a conflict to the change that it came from. Keeps both intents when they fit together, and asks when they do not. Then runs the checks on the combined result. Not for choosing what a new behavior should be (use `choose-by-consequence`).

Use when fixing a bug, a regression, or a confirmed review finding. Also use it when the user says "fix this bug", "it is broken", or "keep the change small". Reproduces the issue before any fix, with a test, a real command, or the real interface. After the fix, the same reproduction must pass. Keeps the change to confirmed, reachable behavior. Not for checking review comments before a fix (use `verify-review-findings`).

Configure shadowclone clones on this machine. A clone is Claude Code or Codex that works as the user, in Docker, toward a draft pull request. Use it when the user asks for clones, cloud sessions, or a background agent that works as them.

Install and configure shadowclone for the user from start to finish. Use it when the user asks to "set up", install, configure, or start shadowclone with Claude Code, Codex, Cursor, Pi, Antigravity, OpenCode, or another agent.

Read before acting for the selected working preferences.

Use when `guided-pr-review` runs it, or when a review packet from `shadowclone review` arrives. Also use it when the user asks only for findings, such as "find bugs in this pull request" or "is this PR safe to merge?". A plain "review PR 123" goes to `guided-pr-review`. Runs a strict adversarial review that covers every changed hunk. It searches for correctness, security, concurrency, side-effect, and compatibility defects, and a judge tests each candidate. A rejection must quote code, and an undecided candidate stays visible. Not for checking review comments that someone else wrote (use `verify-review-findings`).

Use when adding, changing, or reviewing tests. Also use it when the user says "add a regression test", "write the test first", or "make sure this cannot break again". Writes a few tests that each name a bug and check the result where the user sees it. Expected values come from an independent source, and each test fails without the change. Test first is an ordering choice inside this skill. Not for checking finished work against the real command output (use `verify-and-review`).

Use before you say that work is done, fixed, or ready for review. Also use it when the user says "make sure it works", "verify this", or "is it ready?". Runs the command or page that the user will use, and reads every count, status line, and exit code. Reviews the whole diff, and labels each claim as measured, inferred, or not verified. This catches a wrong count or a buried warning before handoff. Not for writing or proving tests (use `tests-that-catch-bugs`).

Use when a pull request has review comments or bot findings to check or address. Also use it for "are these comments right?", "triage the review", "address the review comments", "check the PR comments", or "check what the bot found". Checks each finding against the code at the head of the pull request, and confirms the file, the line, and the claim. Fixes each confirmed finding without waiting, replies by fixed rules, and reports each verdict. Asks the user before it declines a human comment. Not for writing a fix from a bug report (use `scope-confirmed-changes`).

Use when writing or editing prose that people read, such as documents, pull requests, commit messages, review comments, chat replies, or skills. Also use it when the user says "make this clearer", "simplify the wording", or "this is a wall of text". Rewrites the text in plain technical English, with one idea in each sentence and no dashes. Then runs a checker that reports long sentences and dashes. Not for checking code behavior (use `verify-and-review`).