Ship the issue-sweep pipeline as a runnable workflow script

[nonreagent]

Problem

The issue-sweep skill describes its per-item pipeline (plan → build → review → fix → verify) in prose and a stage-prompt reference, but ships no executable. Every sweep re-derives a Workflow script from that prose, and the script then dies in a session directory on a disposable machine.

Motivation

Two sweeps in two nights re-wrote the same harness. The workflow rule added in #21 says a session that produces a reusable executable commits it into the package it serves, parameterized and scrubbed. risk-sweep already ships its script this way; issue-sweep should match.

Proposed Solution

Add scripts/workflow.js beside the skill and a Reference bullet pointing at it. The script is a worker pool that holds recon's concurrency cap (each item still walks its own stages end to end, no barrier between items), with the five stage prompts assembled from the skill's recipes. Everything repo- and machine-specific arrives through args: repo, checkout path, default branch, the shared context block from recon, the tracker disclaimer line, worker count, the build model's trailer name, and the items with their hints, dependency lists, and optionally a committed plan path plus orchestrator overrides. An item with planPath switches stage 1 into "confirm the committed plan and brief the deviations" mode. Close of run (CI judged once, promotion, cleanup check, the report) stays with the orchestrator, as the skill says.

Verified by running this exact pipeline shape on a four-item sweep the same night (14 agents, no errors, four reviewed PRs), then parameterizing the repo-specific strings out. Syntax-checked under the same async wrapper the harness applies.

Feedback

Two calls worth a second opinion. First, the worker pool instead of pipeline(): the harness already caps concurrency, but the pool makes "N items in flight" the orchestrator's number rather than an incidental one, at the cost of a few lines. Second, review and verify inherit the session model by default rather than taking an explicit tier, on the reasoning that the orchestrator runs on the strongest tier available and those two stages must too. Say if you would rather both be explicit args.