afk.sh: chaining /implement over ready-for-agent tickets overnight, one fresh session per ticket

[Warshoow]

I've been using the skills workflow for a while, and the part I wanted to stop babysitting was the end of it: once /triage has labelled a batch ready-for-agent, running /implement on each ticket one by one. So I wrote an outer loop for it.

afk.sh takes the ready-for-agent tickets, orders them by their "Blocked by" lines, and runs /implement on each one in a fresh headless Claude Code session, in its own worktree. One ticket, one session, one PR. The loop itself is plain bash with no model in it: it runs your own test command on each branch, and a red gate means a red ticket, whatever the session said. Dependent tickets are stacked on their blocker's branch, independent ones can run in parallel. It merges nothing.

Where it sits in the workflow:

/grill-with-docs → /to-tickets → /triage → /afk-preflight → ./afk.sh → /afk-debrief → you merge

It adds three skills around the loop:

• /afk-setup writes a .afk.env with the command that means "done" in this repo
• /afk-preflight rereads the batch before the run and catches what would waste the night: a ticket frozen by a blocker outside the batch, a criterion no gate can check, two tickets editing the same files
• /afk-debrief reads the run's summary in the morning and sorts each red by cause (wrong gate, ticket too big, real failure)

Last run: 10 tickets, all green on the first attempt, $20.40, 62 minutes. At the end it merged the green branches together and set 3 aside because they all touched the same test file. Not every run goes that well; RUNS.md in the repo logs all of them, bad ones included.

Related to #1091, which is the same use case from the inside: afk.sh doesn't fix the three points raised there, since it calls /implement as is. What it does is not rely on the session's own review: the gate is your test command, run by the loop after the session ends. And /afk-preflight is close to the staging step suggested there (an attended session rereads the batch before the run), though it doesn't draft seams. I've opened issues on my side to check whether afk's runs hit points 1 and 2, and to look at seams in /afk-preflight.

Repo (with a one-minute video tour): https://github.com/Warshoow/afk.sh

If you run the workflow unattended too, I'd like to hear how you decide a ticket is actually done.

[Warshoow]

Update on the two points from #1091 I said I'd check. Both were hitting afk's runs. Across the 173 sessions on my machine, /tdd never ran once, and the review was the built-in one twice as often as the plugin's.

afk's prompt now names the skills in full, puts the review after the commit, and uses the ticket's acceptance criteria as the confirmed seams for /tdd (details in #1091). I haven't seen it on a real run yet. The next one will show whether tdd actually gets called.

The same batch of fixes also changes three other things:

• tickets written by someone with no rights on the repo are skipped, since their body goes to a bypassPermissions session
• relaunching a red ticket keeps its old branch as afk-prev/<n>
• the run prints which Claude account it's using