afkkit

The away-from-keyboard runner. Hand it a groomed ready issue and it drives the middle of the dev workflow from an isolated worktree to an open pull request: implement and commit, write and run the QA plan, check the result against the issue, fix, open the PR, and flip the issue to in-review. The human gates stay where judgment lives: planning and grilling happen before (the ready label is the entry contract), review and merge happen after. Deep code review also happens after: a PR-level review bot covers the diff once the PR opens, so afkkit runs exactly one acceptance check in-span.

afkkit adds no worktree, tracker, or PR behavior of its own. It sequences companion kits (issuekit start at the front, then implementkit, commitkit, qakit, reviewkit, and prkit) and owns exactly one thing they don't: the escalation policy that decides, at every step, whether to keep going or stop cleanly and leave the issue for a human.

The contract

• Input: an issue number, or all. afkkit invokes issuekit start <n> itself, and issuekit refuses anything not labeled ready, gets the worktree from gitkit (off a freshly resolved base ref, adopting an existing one rather than recreating it), flips ready → in-progress, and runs the repo's declared worktree setup through gitkit prepare. That guard is the safety property, and it holds no matter who types the command: an issue only reaches ready after a human grill session, and afkkit can neither promote an issue to ready nor start one that isn't.
• Authorization: naming the issue, or the single OK on an all queue, is the user's authorization for exactly these actions on each issue: acquire the worktree through issuekit start, including the worktree setup the repo declares, write commits on the issue's own branch, push that branch once at the PR step, and open its PR through prkit. afkkit states this authorization to every companion kit it invokes and in every dispatch prompt, and prkit takes it as its preview OK for the QA-plan commit and PR creation. Label writes need no authorization, because their owning skills exempt them for every caller. Any action outside this list still needs consent, so the run escalates on it: a force-push, a rebase of a published branch, a push to another branch, a merge. The one way to widen the list is in writing, in the issue body: an outward action the body pre-approves by name (a grill records these, such as "may file follow-up issues") joins the list for that issue only.
• Output on success: an open PR whose body opens with the decisions the run took on the user's behalf, as text under Assumptions, then carries any unmet acceptance criteria and a pointer to a committed QA plan holding the automated results, plus the issue moved to in-review.
• Output on a blocked run: no PR. The worktree and its commits stay intact, a comment on the issue names the precise stuck-state, the issue is labeled for whoever must pick it up, and, in a batch, the next issue starts. afkkit never publishes half-broken work: every commit before the PR step runs with commitkit's no-push, so the branch reaches origin only when prkit opens the PR.

When this fires

• one issue. "afkkit 42", "run #42 unattended", "autopilot issue 42", "take #42 to a PR".
• the whole ready queue. "afkkit all", "work the ready issues while I'm away", "drain the ready backlog".

If the user names neither an issue number nor all, ask which. afkkit never plans, grills, merges, or responds to PR review feedback (see Non-goals).