board-pilotlisted

Generic, board-driven implementation pipeline: polls a GitHub Project on a schedule, ARMS an item the moment a human drags it into the configured trigger column, then advances it one stage per tick — each stage a Bridge primitive (skill / workflow / agent / cmd) — and STOPS at a human-gated draft PR. The engine is project-agnostic; everything project-specific (which stages, which handlers, the trigger column, the rework budget, the criteria each stage judges against) lives in per-project `board:`/`pipeline:` blocks in workflow/projects/<slug>.yaml. An engine-owned `Pipeline` field is the durable program counter, kept distinct from the human-owned `Status` column, so a person moving a card mid-flight can never corrupt the state machine. Fail-closed engine guards: PAUSED kill-file, atomic snapshot, lock liveness via kill -0, argv-safe handlers, draft PRs, byte-0 reject marker, board-option preflight, a durable rework cap, blind-rework park, engine-written evidence, and a human-Done halt (the token ceiling is IN
bks-lab/open-bridge · ★ 8 · AI & Automation · score 74

Install: claude install-skill bks-lab/open-bridge

# board-pilot A **generic, board-driven implementation pipeline**. It watches a GitHub Project, and when a human drags an item into the trigger column it drives that item autonomously — stage by stage, each stage a Bridge primitive — to a **human-gated draft pull request**, then stops. No project specifics live in the engine; a project declares its own pipeline in config. The same engine runs a heavy project (full implement→verify→review) and a light one (a two-stage doc edit) unchanged. > **What it is NOT.** Not a merge bot, not a board-sync tool (that is > `tracker-sync`), not a write executor for board fields (that is > `github-projects-manager`). board-pilot only *advances* an item to a draft PR > and hands the merge decision back to a human. ## Mental model - **Poller-fast / worker-slow split.** A cheap cron tick (`Engine.tick()`) runs often (~1 min). It contains **no LLM** — it only reads the board, arms new items, and advances each in-flight item by exactly **one** stage under a per-item lock. The slow work (a `claude -p` implement run, a workflow harness) happens *inside* a dispatched stage; the next tick re-reads the board to confirm before advancing again (confirmed-advance). A 1-minute poll therefore never double-dispatches a 20-minute job. - **Decision A — engine-owned `Pipeline` vs human-owned `Status`.** Each board item carries two fields: - **`Status`** — the human lifecycle column (e.g. `Backlog → Ready → Ready for Development → In Pro