arbeitsplan-runlisted

Executes a compiled workflow as a redundant swarm — N candidates over the same scope in their own git worktrees, judged blind, exactly one landed. Use after arbeitsplan-compile, or when the user asks to run the workflow, start the swarm, or build several versions and pick one. Halts and surfaces rather than retrying when candidates fail; convergence comes from widening, never from repeating. Writes only inside candidate worktrees until the landing step.
Anselmoo/werkstoff · ★ 1 · Code & Development · score 70

Install: claude install-skill Anselmoo/werkstoff

# Run the swarm N candidates build the **same scope** in isolation. Exactly one lands. The rest are deleted. That is what makes a merge conflict impossible here: this is the same worktree isolation `superpowers` uses, inverted. There, N worktrees do *different* work and must all be reconciled — which is why `subagent-driven-development` forbids parallel implementers inside one worktree "(conflicts)" and pushes the parallelism up to where the conflicts reappear. Here, N worktrees do *the same* work and N−1 are discarded. Nothing is ever merged. ## Steps 1. **Read `workflow.json`.** Read the file; do not work from a summary of it. Refuse a `schemaVersion` other than `"2"` rather than guessing at it. Then branch on `backend.kind` — it is a decision the spec already made, never yours to re-make: `workflow` → follow [The workflow backend](#the-workflow-backend) below; `matrix` → `arbeitsplan-matrix`; `in-session` → the steps here. A phase with `mode: "plan"` never runs under the lock: `worktree_pool.py open` refuses it, because plan mode plus an open lock leaves no legal write. Close, run that phase in plan mode, then open the next one. 2. **Open the run scope lock** before any dispatch: ```bash python3 "${CLAUDE_PLUGIN_ROOT}/scripts/worktree_pool.py" open --spec analysis/arbeitsplan/<runId>/workflow.json --phase build ``` This writes `analysis/arbeitsplan/run_scope.json`, which arms the guard. It is a **per-dispatch lock, not repo-level