repair-intake

name	repair-intake
description	Vendor-agnostic repair scanner — the recovery counterpart to lisa:intake. Where intake claims `ready` work, repair-intake finds work that got stuck or was left half-closed: items left in `blocked`, stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items that are still natively open, and rollup/container items whose children are all terminal but whose parent is not closed out. Scans the same queues lisa:intake serves (Notion / Confluence / Linear / GitHub PRD databases; JIRA / GitHub / Linear build queues), enumerates candidates up to `max_candidates`, and repairs every materially actionable one in that bounded set: resumes stalled in-progress work IN PLACE (build → the vendor agent + the scanner's post-agent transition; PRD → the source `*-to-tracker` dry-run validate→route pipeline) — but for a stalled build it first diagnoses the PR/deploy state: a PR that already merged is recovered by applying the env transition build-intake never got to (no re-dispatch); a PR that is merely behind its base is re-synced in place via `gh pr update-branch` so the already-enabled auto-merge can land (a clean rebase needs no human); and only a PR that cannot merge for a non-mechanical reason (true conflict, failing checks, unaddressed CodeRabbit/changes-requested) or a failed deploy gets a build-ready leaf fix ticket with the item moved to `blocked` (blocked by that ticket) rather than re-dispatching, re-validates blocked PRDs when new clarifying answers exist, re-dispatches blocked build items whose `is blocked by` dependencies have since closed OR whose validation/quality-gate self-block now re-validates PASS (re-running `lisa:tracker-validate` against current content — the build mirror of PRD re-validation), performs terminal native closure for terminal-labeled items, reconciles parent rollups to their derived state per leaf-only-lifecycle — including the intermediate-env case (e.g. all children at `On Stg` → parent `On Stg`) and a container wrongly stuck in `ready` — and closes out rollups whose associated child work is fully terminal. Idempotent, loop-protected via a [lisa-repair-intake] marker + state fingerprint + backoff. Never mutates product-owned states (`draft`, `verified`) and never touches `ready` leaves (a container wrongly carrying `ready` is the one exception — it is rolled up from its children, since `ready` on a parent is an invariant violation, not intake's claim signal). Designed as a /schedule cron target running alongside lisa:intake.
allowed-tools	["Skill","Bash","Read","Write","Edit"]

Repair Intake: $ARGUMENTS

Run one batch-repair cycle against the queue identified by $ARGUMENTS. Where lisa:intake scans the ready role and moves work forward, repair-intake scans the stuck and close-out roles and moves work unstuck or fully closed:

• Stalled in-progress — an item left in an in-progress role (build claimed, PRD in_review) whose processing cycle died. It is technically "being worked" but nothing is happening, so it sits ignored forever. (The vendor PRD intakes explicitly leave an errored PRD in in_review "for the human to investigate from there" — that orphan is exactly what this skill recovers.) For a stalled build, repair-intake first diagnoses why it stalled by inspecting its PRs and deploys. A PR that already merged is recovered by applying the env transition build-intake never got to (its merge gate left the item claimed when the merge landed after its agent returned) — no re-dispatch. A PR that is merely behind its base (BEHIND, no conflict) is re-synced in place with gh pr update-branch so the already-enabled auto-merge can finally land — a clean rebase needs no human, and leaving it stranded is the exact gap that lets an auto-merge PR sit unmerged forever. A true merge conflict is first given one bounded in-place re-dispatch to the build agent — whose drive-pr-to-merge fix-mode loop resolves conflicts — because a conflict, unlike a failing external check, is fixable by re-running the build; only a conflict that survives that single attempt (or that the agent says needs design input) becomes a fix ticket. The genuinely non-resolvable blockers — failing checks / unaddressed CodeRabbit or CHANGES_REQUESTED review / a failed deploy — get a build-ready leaf fix ticket with the item moved to blocked (blocked by that ticket) instead of blindly re-dispatching the agent, which would just churn against them.
• Recoverable blocked — an item in blocked whose blocker may now be gone. The blocker is one of three classes, and repair re-checks all of them, not just dependencies: (a) an is blocked by dependency has since closed; (b) a validation / quality-gate self-block — the item was bounced to blocked by its own pre-flight / gate (missing Validation Journey, Sign-in Required, Acceptance Criteria, etc.) with , and a human has since edited the item to add what the gate demanded; or (c) / an research can now settle. A self-block (b) is the common one missed by dependency-only re-checks: nothing else is blocking it, so re-running the same gate against its current content is the only way to know it is now passable.