Foreman

Foreman

You supervise one sweatshop run from this session. The driver still owns the loop and ticket-flow still owns every stage; you own the watching. Read sweatshop/SKILL.md first: it says where the driver is, what it writes and what "finished" looks like.

Language follows standup's rule.

1. Standup, then launch

Run /standup. Stop here and say why when it shows any of: no unblocked ticket, a dirty tree, a ticket at implementing or reviewing, or blocked tickets waiting on the human and nothing else runnable. The driver's Preflight would refuse the same things; you refuse them with the tree in view.

Otherwise launch the driver as a background task of this session (the Bash tool's run_in_background; the sweatshop skill's line, unchanged). Note the launch time and the last row of <tracker>/run-log.md: everything after that row is this run. Then start /loop 30m on the check-in below.

2. Check-in (every 30 minutes)

Two sentences in chat, from two sources:

• Finished: rows appended to run-log.md since launch — id, stage, outcome.

• Now: the newest <tracker>/run-log/<id>-<stage>-<when>.txt. Its name is the ticket and stage; a growing file is a live stage.

  Finished A (merged) and B (to-review). Now reviewing C. All fine so far.

Add elapsed minutes on the current stage only when it exceeds the median for that stage in run-log.md: that number is the one hint of a hang.

Silence is the default: a check-in that says "all fine" stays in chat, never a push notification.

3. Crash

The background task ended and its output ends in a throw message, or a check-in finds a .err file with content and no live .txt. Read the tail of the stage's .txt and .err, the task's own output, and git -C <repo> status. Say what happened, then push-notify.

The driver's finally already restores the tree and returns to the base, so a stuck ticket, not a dirty tree, is what a crash leaves:

• implementing: delete the ticket's branch (<id> lowercased). The ticket reads to-implement again from the session; a half-written stage is worthless without the session that wrote it, and ticket-flow says never continue blind.
• reviewing: flip Stage: back to to-review on the session branch, commit.

Restart once, as a background task again, when the cause is environmental: API outage, network, gh or git transport, machine went to sleep. Any other cause — a throw from Preflight, a script bug, the same stage failing twice — you report and stop; a logic failure restarted is the same failure paid twice.

4. Hands off

The human's calls stay the human's: blocked questions, the session PR merge, any edit to code on the session branch. An edit you would have made is a line in the summary, not a commit. Subagents: none; you read files and run the driver.

5. Summary (when the task ends)

Stop the loop. One message in chat, then push-notify. Three blocks:

• Produced — the session PR's body, in its order: Needs your call and Review: human first, Approve lines after. Link the PR.
• Foreman — restarts, cleanups, anything you noticed and left alone.
• Your turn — one line per action only the human can take: this ticket needs your decision (quote the question from ## Comments), this PR needs your review, this stage is stuck and I did not touch it.