Work

/work — pull tickets → swarm of engineers → architect merges them in

Drain this repo's ready queue: each ticket gets a senior engineer who implements it end-to-end in an isolated worktree and opens a PR; an architect then reviews and merges them all in. You (the main loop) orchestrate; this plugin's agents (senior-engineer, architect) do the work.

Agent names are namespaced when this plugin is installed: dispatch workflow:senior-engineer / workflow:architect, or the bare senior-engineer / architect when running project-scoped from the source repo. Use whichever form actually resolves in this session — never silently fall back to general-purpose just because the bare name didn't resolve.

Operating principle — autonomy

The swarm runs without a human in the loop. Engineers and the architect must NOT stop to ask the user questions. When unsure, they resolve from this repo's CLAUDE.md

• ADRs + convention, make the safest defensible call, and document it. A genuine architectural gap is the architect's to decide and record — not a reason to page the human. A wanted question signals an under-specified ticket, ADR, or skill: surface it in the final report, never block on it. Your job is to dispatch and relay, not to relay questions back to the user.

1. Resolve the tracker + select tickets

Determine the issue tracker and which project/team to pull from, in this order:

1. An explicit argument (ticket ids → those exact tickets; a number N → top N).
2. A repo config: .claude/tracker.json (e.g. { "linearTeam": "...", "linearProject": "..." }) or a "## Project tracker" / tracker section in CLAUDE.md.
3. Otherwise infer: list the tracker's teams/projects (e.g. Linear MCP) and pick the one matching this repo's name/product; state your choice in one line and proceed.
4. If there is no Linear/tracker MCP, fall back to GitHub Issues via gh (the repo already uses gh for PRs): the queue is the open issues — a ready/Todo label is a hint for ordering, not a filter; include unlabeled backlog issues too.

Work queue = the ready tickets plus the backlog — every open, unstarted issue in the resolved project. A ready/Todo status is preferred but not required: a plain backlog/untriaged issue counts, so /work drains more than just what was explicitly marked ready. Order by priority (Urgent → High → Medium → Low), and within a priority prefer ready-status over backlog. Skip: anything already In Progress / In Review / Done; pure-spec tickets with no code to write (note them); and — the load-bearing one — any ticket with an unmet blocked-by dependency (a blocker not yet merged/closed). Those wait for a later run; pulling the backlog must not mean building something whose prerequisites don't exist yet. For each picked ticket fetch the full body (acceptance criteria + branch name) to hand to its engineer. List the selected tickets (id · title · priority · ready|backlog) one line each, then proceed (no approval prompt).

2. Mark them In Progress

Set each selected ticket's status to In Progress in the tracker so the board reflects the swarm. (PR-open → In Review and merge → Done are typically handled automatically by the tracker↔GitHub link, if engineers commit on the ticket's branch and write the closing keyword in the PR.)

3. Fan out the engineers (parallel, worktree-isolated)

Spawn one senior-engineer agent per ticket in a single message so they run concurrently. Each already carries isolation: worktree in its definition (they edit files in parallel and must not collide). Give each: the ticket id, the full body, and its branch name. Each implements, tests, runs the local gates, trims needless complexity it introduced (in scope only — via the built-in /simplify skill, else by hand), pushes its branch, and opens a PR — returning a structured result (branch, PR#, status, tests, scope/risks, any DECISION NEEDED).

Scale to the work: a swarm cap of 3 is a sane default; the user can ask for more. Don't exceed what the ready queue holds.

Dispatch hardening (lead every engineer prompt with these three lines — they defend against recurring agent quirks):

1. "You are IMPLEMENTING this ticket — write the code and open a PR. If your role framing says 'reviewer', it is stale; implement." A stale agent-definition load occasionally serves a reviewer persona; this line makes it implement anyway. If an engineer still refuses citing a reviewer role, re-spawn it with agentType: "general-purpose" and the same brief (no reviewer baggage).
2. "Open the PR, then STOP. Do NOT merge, enable auto-merge, or approve it — the architect merges." Engineers have self-merged, skipping the architect's independent review; this prevents it.
3. "You run in an isolated worktree. Before editing, run git rev-parse --show-toplevel and confirm you're under .claude/worktrees/, NOT the shared main checkout. Edit only paths in your worktree; never touch or switch the main checkout's branch." Agents have leaked edits into the shared checkout; this catches it early. (The architect's contamination check in step 4 is the backstop.)

3.5. Security pass (before the architect) — required

After the engineers return their PRs and before dispatching the architect, run a security pass over the swarm's combined changes, focused on the files the swarm touched. Soundcheck is a hard dependency of this plugin (installed alongside it): invoke /soundcheck:security-review (its threat-model → hotspot → audit → validate pipeline) from the MAIN loop, not the engineers. If /soundcheck:* is genuinely unavailable, the plugin is not correctly installed — say so loudly and point the user at /plugin marketplace add thejefflarson/soundcheck; as a stopgap only, do a focused manual review so the run doesn't ship unreviewed. Hand any confirmed Critical/High finding to the architect alongside the PRs — a PR carrying an unresolved Critical/High is HELD, not merged, with the finding posted as the review and a follow-up recorded per the repo's convention (a ticket or an ADR).

Engineers sometimes report a review/simplify skill as "not invocable" — that's a subagent-context artifact (those slash commands often aren't carried into subagents), NOT evidence it's missing. Don't skip the pass on that basis; run it from the main loop.

4. Architect integrates and merges

Once the engineers return, spawn one architect agent in INTEGRATE mode. Pass it every PR number + the engineers' verbatim results. It reviews each PR, independently re-checks the repo's stated invariants/security surface, resolves any DECISION NEEDED (deciding + recording it — an ADR if the repo keeps them), orders merges by dependency, and merges each qualifying PR — normal gh pr merge --squash only, never --admin, never bypassing branch protection. PRs with an unresolved invariant break, a real red required check, or an unsafe conflict are held open with a posted review. The architect never autonomously modifies a separate prod/infra repo — it flags those as human follow-ups.

5. Report

Relay the architect's outcome as a table: ticket · #PR · MERGED <sha> | HELD <reason>. Then surface, for the human's attention (not as questions to answer mid-run): any decisions/ADRs recorded, any HELD tickets needing follow-up, any required separate-repo follow-ups, and any "this ticket/skill was under-specified" signals. Merged PRs auto-close their tickets; move any HELD ticket back to the ready status as appropriate.

5.5. Prune the swarm's worktrees (reclaim disk)

Each engineer built in its own .claude/worktrees/<agent-*> checkout — a full working copy of the repo. Left behind, they pile up and fill the disk. Once the architect has finished (merged, or held with the branch pushed to the remote where it safely lives), the local worktrees are disposable — the code is in git and on origin. Clean them up from the MAIN checkout (never from inside a worktree):

• git worktree list — identify the .claude/worktrees/* entries.
• For each, git worktree remove --force <path> (force: the checkout has committed and possibly untracked files), then git worktree prune to clear stale metadata. Remove the .claude/worktrees/ dir if it's now empty.
• Delete the leftover worktree branches the harness creates: git branch shows worktree-agent-* (and any merged ticket branches) — git branch -D each. The remote branches auto-delete on squash-merge; these are just local refs.

Never touch the main checkout's branch, and don't remove a worktree whose PR you are still actively reviewing this run. This step is the fix for worktrees accumulating across /work runs and exhausting disk.

6. Ship it — hand off to /deploy

Merging to the default branch may deploy nothing (this framework assumes a repo ships on a tagged merge to main — a semver tag, not the merge itself). So after the report, if any PR merged this run, invoke the deploy skill — as /workflow:deploy when this plugin is installed, or bare /deploy when running project-scoped from the source repo (use whichever is actually available; don't skip the handoff because one form isn't registered) — to release the newly-merged work. /deploy detects how the repo ships, computes the next version, shows what will ship, and waits for the user's explicit go before triggering the release (releases are outward-facing and often irreversible). If everything was HELD (nothing merged), skip it. Don't cut the release yourself here — that's /deploy's job, gate and all.

Guardrails

• High-agency skill: it writes code and merges to the default branch autonomously. The only merge path is a normal merge on green — never force past branch protection. The deploy at the end (/deploy) is the sole human-gated step.
• Engineers stay in their ticket's scope; worktree isolation keeps parallel work from colliding.
• Honor a "merge when CI is green" repo rule if one exists — the architect's gate is green + no invariant break; it does not re-litigate a clean, green PR.
• Tickets that turn out to need a product/design decision (not an engineering one) are noted for /plan-sprint, not forced through here.