terminal-bench-loop

Open a top-level loop issue with the task name, iteration budget, benchmark command, and dispatch config, then create one iteration child per run. Each iteration runs a bounded smoke, diagnoses the stop point, and either proposes a board-gated fix or stops with a named reason.

Apply the /diagnose-why-work-stopped pattern to the smoke's issue subtree: walk each node, find the exact (issue, status) that stopped progress, and classify it as needing human intervention, agent-actionable, or already covered. Record the failure taxonomy bucket on the iteration child.

No. This skill produces smoke runs that are explicitly non-comparable by design. For full-suite or comparable benchmark submissions, escalate to BenchmarkQualityManager and BenchmarkForensics instead of relabeling a smoke run.

The loop tests the same worktree where accepted fixes land, so results reflect the code under change. PAPERCLIPAI_CMD is pinned to that worktree's CLI entrypoint, and later iterations inherit the workspace via inheritExecutionWorkspaceFromIssueId.

Do not use it to build or change paperclip-bench itself, to submit ranked benchmark results, or for ordinary Paperclip bugs not surfaced by a loop. Those cases use normal engineering flow, BenchmarkQualityManager, or standard investigation respectively.

The loop must stop: the loop issue moves to cancelled with a summary of run history, or to in_review if the user must decide whether to extend the budget. Starting another iteration silently is explicitly forbidden.