PLEXI

Land a queue of stint tasks as fast as possible by orchestrating agent instances (Claude or Codex, launched via size-tier aliases) in Plexi panes. You give it stints (or sprints); it spawns every pane it needs: a WORKER pane implements each batch and opens one PR, a separate fresh TESTER pane validates the PR against the real install build, bugs route between them until it passes, then merge and fresh panes for the next batch. The head relays itself to a fresh pane after every merge via RUN_STATE.md. You are the router, never the coder. Checks in every 10 min. Triggered by /babysitter, "babysit the queue", "queue these stints".

Phase 1 of the PLEXI ship pipeline when work is selected from .stint. Resolves a stint task, claims it (stint owns state — no git commit needed), branches a feature worktree from alpha HEAD, implements the task, pushes the branch, then hands off to /open-pr.

Phase 2 of the PLEXI ship pipeline. Takes a pushed feature branch, creates a PR targeting alpha, updates pipeline labels, and invokes /validate-pr inline. Input: branch name or auto-detect from CWD. Output: PR URL.

Phase 4 of the PLEXI ship pipeline. Takes an approved PR number, squash-merges to alpha, closes the issue, and cleans up. Input: PR number. Output: merged alpha.

Phase 3 of the PLEXI ship pipeline. Installs a PR build, generates test instructions, handles user pass/fail/modify responses, and manages the retry loop (max 3 soft rejects before escalating to hard reject). Input: PR number. Output: approved PR number or hard-reject.

Use this skill when the user wants to add a stint task, create a ticket, track a unit of work, file a bug, propose a feature, or log something to .stint/. Triggered by phrases like "add a task", "create a stint", "new task", "track this", "file a bug", "log a ticket", or when planning work that should go in the operating graph.

Agent self-validation before push. Classifies the diff (host logic / host UI / PGAP app), runs the matching harness tests, generates headless render screenshots as evidence, and writes a Test Evidence block for the Ship Log that validate-pr uses to decide whether binary install can be skipped. Invoked inline by implement-issue and implement-stint after cargo build passes, before git push.

Session orientation skill. Re-audits stint tasks, checks open PRs, and rewrites WHATS_NEXT.md (the Arc + Priority Stack). Use at the start of any session when you don't know what to work on next, or after a batch of merges when priorities may have shifted. Also called inline by merge-pr after each merge to keep the file in sync.

Live headed end-to-end loop for validating a PR (or any channel) build against a real running Plexi host. Boots the host with `plexi host start`, drives it with pane/events commands, observes ground truth from pane state/capture and the channel log, then tears it down. Use when a change can only be verified in the installed binary (PTY/terminal flows, menus, dock, real multi-pane behavior) — not for anything a headless harness can cover.

Standalone PR testing skill. Installs a PR build, reads the issue spec, writes test instructions, and returns pass/fail. Works independently — does not require being in a ship pipeline session. Input: PR number or issue number.

Phase 1 of the PLEXI ship pipeline. Finds an issue, sets up a worktree, implements the code changes, pushes the feature branch, then invokes /open-pr inline in the same pane. Entry points: /implement-issue (auto-find), /implement-issue <n> (specific), /implement-issue P1 (by priority), /implement-issue <n> <m> [...] (bundle).

Use when the user wants to run one or more tasks in parallel lanes. Each lane is a separate pane in a sub-context. Lanes can be issue numbers (/implement-issue), stint IDs (/implement-stint), bundles of issues, or any arbitrary prompt. No argument type is required — dispatch is general-purpose.

Use this skill when the user wants to create a GitHub issue, file a bug, propose a feature, or log a task on a repo. Triggered by phrases like "create an issue", "file an issue", "open an issue", "log a ticket", or "add a GitHub issue".

Operating inside Plexi — spawn/name panes, focus, launch apps, manage contexts, surface notifications. Use when working in a Plexi pane or orchestrating other panes.

Reactive 4-lane dispatcher. Keeps up to 4 agent panes running at all times — fills empty slots from the PRM-aligned ready queue, watches on a timer, and refills as lanes complete. Use when starting a dispatch session, told to watch the queue, or asked to keep agents running. Not for single-issue work — use /implement-issue for that.

Split the current pane, launch a command in the new pane, confirm it started, then close self. Use when explicitly transferring work to a different agent or pane — e.g. escalating a hard reject, handing off to a human, or launching a parallel task. Not for the standard ship pipeline (those chain inline). Requires PLEXI_PANE_ID.

Summarize active agent panes from host-managed pane slots: what each lane is doing, waiting on, and needs from Ian.

Use when a PR attempt has failed and needs to be abandoned — close without merging, audit what went wrong, rewrite the issue so the next agent starts closer to done with fewer wrong turns.