/check

description: Quick sanity check - code (inline 6-perspective) or plan (--plan).
argument-hint: "[PR-url-or-number|--local|--staged|--last-commit|--branch|--plan|--file <path>] [--json] [--spec <path>|none] [--fix] [--solo]"

Quick Local Code Check

Fast inline sanity check from 6 perspectives. Same target selection as `/lets:review` - the difference is depth: `/lets:check` asks no AskUserQuestion gate and spawns no subagent - one reviewer verifies its own findings, inline or, in a team worktree, the team's live skeptic member (a message to an existing agent, never a spawn); `/lets:review` dispatches expert agents.

Usage

/lets:check                      # uncommitted changes (default, same as --local)
/lets:check --local              # uncommitted changes (explicit)
/lets:check --staged             # only staged changes
/lets:check --last-commit        # last commit
/lets:check --branch             # full branch vs $LETS_MERGE_BRANCH (three-dot, like a PR)
/lets:check <PR-url-or-number>   # quick PR sanity (gh pr diff, inline - no agents)
/lets:check --file <path>        # quick sanity of an existing file (full content, not a diff)
/lets:check --plan               # quick plan sanity check
/lets:check --plan <path>        # quick sanity of a specific plan file
/lets:check ... --json           # structured JSON output instead of console report
/lets:check --spec <path>        # use this file as the spec (or a bare task id)
/lets:check --spec none          # there is deliberately no spec - no spec block, no caveat
/lets:check ... --fix            # verify each finding, then apply the fixes when nothing needs deciding (not with --json)
/lets:check ... --solo           # in a team worktree: inline, not on the team's skeptic member

When to Use

• Quick sanity check during development
• Before commit for significant changes
• When unsure if code is ready
• Spot check after refactoring
• Fast first pass on a PR before a full `/lets:review`

**For full review:** Use `/lets:review` (same modes, multiple expert agents, deeper analysis). Every mode below has a `/lets:review --<same-flag>` upgrade path.

Step 0: Determine Mode

Parse the argument(s):

| Argument | Mode | Target | |----------|------|--------| | `--plan` / `--plan <path>` | Plan review | go to **Plan Mode** section below, skip code steps | | `--file <path>` | File review | entire file content (not a diff) | | bare PR URL or number (not a flag) | PR | `gh pr diff <PR>` | | `--local` / *no argument* | Local (default) | `git diff` (uncommitted) | | `--staged` | Local | `git diff --staged` | | `--last-commit` | Local | `git diff HEAD~1` | | `--branch` | Local | three-dot merge-base diff against the base the Step 1 guard resolves (`origin/{LETS_MERGE_BRANCH}` when it exists) |

`--json` is a modifier that can accompany any code mode (not plan mode): emit structured JSON instead of the console report (see Step 4.5). Skip the LETS box and the tracker comment when `--json` is set - the caller handles output.

`--fix` applies the findings at the end: Step 3.5 verifies them, Step 5.5 applies them through the `apply-fixes` skill (the gates live there). The user typing it is the write authorization for this run. With `--json` -> refused, one line: `--fix edits files - --json has no side effects`. PR mode -> add `headRefOid` to the Step 1 `gh pr view` fields (bitbucket: the source commit); `git rev-parse HEAD` not equal to it -> drop `--fix` with one line (check never moves HEAD). `--plan` -> the plan file only.

`--spec` is the other modifier: `--spec <path>` uses that file, `--spec none` declares there is no spec, a bare task id resolves through the tracker. It short-circuits Step 2's resolution entirely. **`/lets:check` asks no question about this and never will** - `/lets:review` has the picker because it is the considered checkpoint, run once or twice; check is fired repeatedly while writing code and takes the flag instead. Same control, no interruption.

`--solo` keeps the pass inline in a team worktree (**Team mode** below).

**In every mode check spawns no subagent: one reviewer verifies its own findings - inline, or in a team worktree the team's live skeptic member (a message to an existing agent, never a spawn)** - **Team mode** below. PR and file modes just change what gets fed to Step 3's 6 lenses.

Team mode (team worktree)

Read `${CLAUDE_PLUGIN_ROOT}/protocol/agents.md` (`## Team mode`) before this branch unless its text is in your current context. Runs for the local modes, `--file` and `--plan` - here in Step 0, so `--plan` reaches it before Plan Mode branches off. In this order, the first that applies:

• `--solo` or `--json` -> inline (`--json`: tooling needs the result in this turn).
• PR mode stays inline: it needs `gh` / `bbb`, which the skeptic's Bash allowlist (`git log/blame/show/diff, ls, find, wc, cat, head, tail` - identical for every analyst, pinned by agentreport_test.go's `reportOnlyWrite`) does not grant; in a team worktree (`lets worktree info --json` reports a `team`) one line `PR check: inline - the team skeptic cannot fetch a PR`.
• Otherwise `Skill(skill: "lets:member-run", args: "op=route command=check roles=skeptic ask=no fallback=inline")`. `TEAM off`, or the skeptic line is not `member` -> continue inline exactly as today, with no question.
• A member line -> the lead resolves only references - the mode, the printed `BASE` (`--branch`: Step 1's guard prints it), the file or plan path, the spec source (`--spec` value; a tracker spec: the lead runs `show` and injects the description fenced and sanitized as Step 2 does - tracker verbs are orchestrator-only) - then `Skill(skill: "lets:agent-report", args: "op=open command=check task={task-id} names=skeptic")` and ONE brief to the member, written to `.lets/cache/route-<REPORT_DIR basename>-<name>.md` (line 1 its `REPORT_FILE:`) and sent with `Skill(skill: "lets:member-run", args: "op=next scope=<c> name=<name> id=<agentId> bri