# Check > Use when screening or replying to pull-request review comments and bot findings; decide if each comment is real, worth fixing, deferred, or declined. - Skill: `tony/check` (Agent Skill) - Install (CLI): `npx skillmds@latest add tony/check` - Raw SKILL.md: https://api.skillmd.com/api/skills/tony/check/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tony (https://skillmd.com/u/tony) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tony/check --- # `/respond:check` Screen review feedback and decide what deserves a fix. Every claim — from a colleague, from a bot, from a review command run earlier in this session — is tested against six gates and leaves with a verdict, its evidence, and a reply the reviewer can argue with. **This skill changes nothing.** No edits, no commits, no comments posted, no threads resolved. Its entire output is a ledger and a recommendation; acting on it is `/respond:action`'s job. That is also why this skill can be routed to on the model's initiative while `/respond:action` and `/respond:goal` cannot: reaching for screening when someone pastes a review costs a report and nothing else. ## Core thesis A review is a set of claims, and a claim is not a work order. The expensive mistakes are symmetrical: a branch that fixes everything a reviewer says grows tests, guards, and comments that nobody can later justify; a branch that dismisses what a reviewer says ships the bug. Screening separates the two before any code moves, and it separates them *on the record* — every verdict carries the evidence that produced it, so a reviewer who disagrees can attack the evidence instead of the judgment. The screening question is never only "is this correct?" It is: 1. Is it **true** of the code as written? 2. Did **this branch** cause it? 3. Is it right **for this project**, against the decisions the project has already made and written down? 4. How **often** does the scenario it describes actually fire, and what happens when it does? 5. What would the fix **cost** everyone who reads the file afterward? The rubric that answers these is `../../references/screening-rubric.md` and it is the authority; this skill collects the inputs and reports the outputs. ## `$ARGUMENTS` contract Non-flag text is the findings list. With no arguments and no `--pr`, look for review output already in this session; if there is none, ask for the feedback rather than inventing a review. | Flag | Default | Effect | |---|---|---| | `--pr=` | current branch's PR when one exists | Collect from the PR's reviews, inline comments, and threads. | | `--base=` | merge-base with `origin/` | Override the provenance baseline (a stacked branch's parent, for instance). | | `--include-resolved` | off | Screen resolved and outdated threads too, instead of treating them as already settled. | ## Phase 0: What this project has already decided The alignment gate needs citations, so gather them before reading a single finding: `AGENTS.md` / `CLAUDE.md` and any nested equivalents covering the touched directories, `.github/CONTRIBUTING.md`, and the branch's own stated purpose — its pull request body, its commit messages, its ticket. Resolve the provenance base here too (see the rubric's Provenance gate), and note the branch's push state with `git status -sb`. A project with nothing written down has made no decisions to cite, which means the alignment gate will rarely fire. That is the correct outcome, not a reason to substitute a preference for a citation. ## Phase 1: Collect Gather from every channel `../../references/feedback-sources.md` describes that applies to this run: pasted text, this session's earlier review output, the pull request's three comment surfaces, and failing CI. Normalize each claim into a finding record, split multi-claim comments into separate findings, drop the approvals and summaries that assert nothing, and merge duplicates — the same defect from four reviewers is one finding with four sources. Carry forward the declines from any previous round in this session: a bot re-posting a finding that was already declined, against code that has not changed since, does not get screened twice. ## Phase 2: Screen Run the six gates on every finding, in the rubric's order, stopping at the first gate that settles it. Record each gate's evidence as you go — the diff that settled provenance, the citation that settled alignment, the trigger that settled odds. A verdict with no evidence behind it is not a verdict, and the report must not contain one. Two disciplines while screening: - **Read the code, do not trust the claim.** Automated reviewers assert with total confidence regardless of whether they are right, and three bots agreeing is one opinion repeated, not corroboration. - **Cost the smallest fix that works**, not the one the reviewer proposed. Reviewers routinely propose a mechanism where a condition would do, and the cost gate should judge the cheaper option. Use `AskUserQuestion` for `ask` verdicts only — findings where the truth depends on intent only the author has, or where the alignment citation is genuinely contested. Everything else is decided here. ## Phase 3: Report — the output contract 1. Hero block (1–3 lines): `N to fix, M deferred, K declined` plus the branch name and the feedback sources screened. 2. `## Ledger` — one entry per finding: id, source (author, and whether it is a bot), the claim quoted, location, the gate results with their evidence, and the verdict with its reason. Merged duplicates list all their sources on one entry. 3. `## To fix` — the accepted findings in the order they should land, each with the minimal fix and whether it wants a forward commit or a `fixup!`. 4. `## Deferred & declined` — with the follow-up recommendation or the drafted reply. A declined `improbable` reply states the trigger the scenario needs, so a reviewer who knows a caller that produces it can say so. 5. `## Ledger key` — branch, `HEAD` SHA, and the feedback digest. This is what `/respond:action` checks to know the screening still describes the current tree. 6. End with an `AskUserQuestion` panel: run `/respond:action` on the accepted findings, run it with `--reply` so the drafted replies get posted too, re-screen with the deferred findings opted in, or stop. In a non-interactive run (CI, subagent) record the panel's options in the report and stop. Nothing in this phase edits, commits, or posts. If the run reaches a point where a fix seems obvious enough to just do, that is the failure mode this skill exists to prevent — write it in `## To fix` and hand off.