verifylisted

# /verify — prove it works Tests passing and a feature working are different claims. This skill makes both, separately, and says which one it can actually support. Run it after `/implement`, before opening a pull request, or against someone's pull request when you want more than a reading of the diff. Local only. It never touches a live system and never writes to the pull request. ## Arguments - **nothing** — verify the current working tree against the base branch. - **`<pr-number>`** — check out that pull request's head in a worktree and verify it. - **`<branch>`** — verify that branch. - `--tests-only` — skip driving the runtime; just run the suite. - `--report` — write `VERIFY.md`. Otherwise the verdict stays in chat. ## Step 1 — Preflight, and be honest about blockers Read `.claude/repo-profile.json` (see `reference/repo-profile.md`). Check, and report all of these together in one block rather than discovering them one at a time: - Is there a test command at all? Many repositories here have none. - Is the execution environment available? For `exec.kind: compose`, is the service up (`docker compose ps`)? For `image`, is the Docker daemon running? If Docker is down and the profile expects it, that is a `SETUP` blocker — starting it is usually the whole fix. - Are dependencies installed? (`vendor/`, `node_modules/` as applicable) - Is there a `timeoutTool`? - Does the runtime surface need something you do not have — a host application, a credential, an externa