/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]"

Quick Local Code Check

Fast inline sanity check from 6 perspectives. Same target selection as `/lets:review` - the difference is depth: `/lets:check` reviews inline (no subagent dispatch, no AskUserQuestion gates), `/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

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.

`--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.

**This command never dispatches subagents in any mode** - all review is inline (Step 3's 6 lenses). PR and file modes just change what gets fed to those lenses.

Plan Mode (--plan)

If `--plan` flag detected, switch to plan review mode. Skip all code review steps below.

If no path was passed to `--plan`, use the **detect-task** skill to find the active task: `Skill(skill: "lets:detect-task")` - the orchestrator substitutes its id for `{task-id}` below, so trunk-mode resolves the plan by task-id (not the branch name).

LETS_PROJECT_ROOT=$(git rev-parse --show-toplevel)
BRANCH=$(git branch --show-current)
PLAN=""

# Explicit path wins: /lets:check --plan path/to/plan.md - use it directly and skip this derivation.

# Derive slug: trunk-mode uses task-id (plan.md saves <date>-<task-id>.md on the merge-branch);
# otherwise the branch slug (covers feature/* and worktree-* branches).
# {task-id} is substituted by the orchestrator from the detect-task result above.
if [ "$BRANCH" = "{LETS_MERGE_BRANCH}" ]; then
  SLUG="{task-id}"
else
  SLUG="${BRANCH#feature/}"
fi

# Guard: empty slug (detached HEAD, or unresolved task-id in trunk-mode) would collapse the glob
# to *.md -> global latest -> another worktree's plan (the bug this fixes).
if [ -z "$SLUG" ]; then
  PLAN=""
else
  # Latest plan for THIS slug - matches date-prefixed (YYYY-MM-DD-HHMM-<slug>.md) and legacy bare
  # <slug>.md. Slug-scoped, NOT global `ls -t`: .lets/plans is shared across worktrees via symlink.
  PLAN=$(ls -t "$LETS_PROJECT_ROOT/.lets/plans/"*"${SLUG}"*.md 2>/dev/null | head -1)
  # Fallback: glob match by task-id (catches trunk-mode plans + naming drift, e.g. plan-workflow output)
  if [ -z "$PLAN" ] && [ -n "{task-id}" ]; then
    PLAN=$(ls -t "$LETS_PROJECT_ROOT/.lets/plans/"*"{task-id}"*.md 2>/dev/null | head -1)
  fi
fi

If no plan found: "No plan found for this branch in `.lets/plans/`. Run `/lets:plan` first, or pass a path: `/lets:check --plan <path>`."

Read the plan and review with 5 lenses (same confidence filter):

• **[Feasibility]** Can this be implemented as described? Missing steps, impossible constraints?
• **[Completeness]** Are all requirements covered? Edge cases? Error handling?
• **[Risk]** What could go wrong? Dependencies, breaking changes, migration risks?
• **[Scope]** Is the plan proportional to the problem? Overengineered? Underspecified?
• **[Clarity]** Can a developer follow this without guessing? Ambiguous steps?

Output same format as code check, then:

┌─ LETS ────────────────────────────────────┐
│  Full review?  /lets:review --plan        │
│  Execute?      /lets:execute              │
└───────────────────────────────────────────┘

---

Step 1: Get Target

Local mode (`--local` / default / `--staged` / `--last-commit` / `--branch`):

git diff                                    # default /