running-check-scriptlisted

# Running the `check` Script This skill is the **single source of truth** for executing the `package.json` `check` script in lt-dev workflows. Every reviewer, rebaser, and orchestrator that needs to guarantee project runnability must follow this procedure verbatim — duplicating the rules across agents leads to drift. > **Goal:** A truly green `check` run (exit 0) is a non-negotiable prerequisite for any review or rebase to be considered complete. The only acceptable residual is an upstream dependency vulnerability where the full fix escalation ladder has been exhausted. ## When to Use This Skill | Caller | Phase | Trigger | Mode | |--------|-------|---------|------| | `/lt-dev:review` | Phase 1.5 | Before spawning any specialized reviewer | Advisory | | `lt-dev:code-reviewer` | Phase 1.5 | Before single-pass review (skip if orchestrator already ran it) | Advisory | | `lt-dev:test-reviewer` | (input briefing) | Honors the skip semantics defined here | Advisory | | `/lt-dev:take-ticket` | STEP 8 | After all test pillars are green | **Blocking** | | `/lt-dev:git:ship` | STEP 1, STEP 4b | Pre-flight, and after the post-rebase re-verify | **Blocking** | | `/lt-dev:ticket-cycle` | via take-ticket + git:ship | Whole cycle | **Blocking** | | `lt-dev:branch-rebaser` | Phase 6.5 | After lint/format, before tests | **Blocking** | ## Caller modes The procedure is identical in both modes. Only what happens with an unresolved error differs, and that difference is the whole point of t