From brain-os
Converts goals, tasks, or issues into autonomous work by routing to clarification (/grill), slicing (/slice), and implementation skills. Handles issue relabeling and spine health checks.
How this skill is triggered — by the user, by Claude, or both
Slash command
/brain-os:afkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
One command from "here's what I want" to "the machine finishes it while you're away." This skill is thin glue: it owns NO clarifying, slicing, or implementing logic — it routes between the skills that do, then verifies the autonomous spine is alive before promising autonomy.
One command from "here's what I want" to "the machine finishes it while you're away." This skill is thin glue: it owns NO clarifying, slicing, or implementing logic — it routes between the skills that do, then verifies the autonomous spine is alive before promising autonomy.
The spine it hands off to (what runs after you walk away):
| Stage | Owner | Cadence |
|---|---|---|
| Dispatch | pickup-auto launchd job → claims status:ready + owner:bot issues → spawns /impl workers | every 2h |
| Recovery | "Story doctor (loop closer)" Orca automation — finds AFK gave up dead-ends, runs /debug, files fix issues, re-queues | 3×/day |
| Learning | /impl auto-invokes /improve on result != pass + "Improve skills (daily)" Orca automation | per-failure + nightly |
Classify the argument FIRST — the three modes share the spine check and report but differ in how work reaches the queue:
| Input shape | Mode | Path |
|---|---|---|
Issue number (/afk 123, /afk #123) | issue | relabel for AFK → spine check → handoff |
| Clear task — single deliverable, no open design decisions, a verifiable done-check, known repo | task | file one issue → spine check → handoff |
| Fuzzy goal, multi-decision, architectural, or you're unsure | goal | /grill → /slice → spine check → handoff |
Default to goal mode whenever classification is uncertain. A wrongly-skipped grill ships the wrong thing autonomously; a wrongly-run grill costs a few questions. Never silently guess task-shaped.
Route by topic shape:
/grill-fast/grillThe grill is the human-judgment head of the loop — do not shortcut it. Proceed to step 2 only when the session is settled (status: pass|settled) and has ≥1 acceptance bullet with the (LIVE E2E) marker (that's /slice's hard gate — failing it later just wastes a step). If the grill ends reflection or working, stop and report: no autonomy possible yet, the goal isn't clarified.
Invoke /slice on the settled grill session → parent story + tracer-bullet child issues on the tracker. Do not duplicate or pre-check /slice's gates (e2e AC existence, AC coverage, rung-0) — it enforces them itself and aborts loudly when they fail.
Skip grill and slice — but NOT issue hygiene. Draft the issue, show it, file it:
## Acceptance (verifiable observables — if you can't write a concrete done-check, the task wasn't task-shaped; fall back to goal mode), ## Files, Observable: line.owner:human; tell the user the machine won't take it and it routes through /pickup.gh issue create):bash "${CLAUDE_PLUGIN_ROOT}/scripts/gh-tasks/create-task-issue.sh" \
--title "..." --body "..." --area <area> --owner bot \
--priority p2 --weight <quick|heavy> --status ready
The differentiator vs /impl <N>: /impl N executes the issue NOW in this session; /afk N queues it for the schedulers and walks away.
gh issue view <N> — read body + labels fresh.owner:human — refuse to relabel, point at /pickup <N>.owner:bot + status:ready (apply the same trunk-path depth gate as task mode before flipping).## Acceptance, add one (confirmed with the user) — an AFK worker without a done-check just guesses.The whole point of /afk over a bare /slice is this check — filed issues sit forever if the schedulers are dead:
launchctl list | grep -q pickup-auto # dispatcher loaded?
orca status >/dev/null 2>&1 # Orca runtime reachable?
orca automations list # "Story doctor" + "Improve skills" present + enabled?
All green → proceed to step 4. Any check red → still keep the filed issues (they wait safely in the queue), but report exactly which spine component is down and how to revive it:
launchctl load ~/Library/LaunchAgents/<pickup-auto plist>orca open (automations don't fire without it)orca automations edit <id> --enabledLog partial in that case — never claim autonomy on a dead spine.
End with a compact handoff report:
owner:bot) / Y HITL (owner:human) — list the HITL ones explicitly; the machine will NOT touch them, they wait for /pickup. Include the rung-0 child number.~/.local/state/impl-story/<parent>.status, or /statusBe honest about partial autonomy: if most children are HITL, say so — "autonomy engaged" on a 90%-human story is a lie.
pickup-auto is the single dispatcher; a second dispatch path causes claim/label races. If the user wants one issue done NOW and visibly, point them at cox <N> or /impl <N> instead.owner:human children to inflate the autonomy number.create-task-issue.sh only — it validates the label canon; inline gh issue create re-introduces label drift.Append one line to {vault}/daily/skill-outcomes/afk.log (per skill-spec.md § 11):
{date} | afk | {action} | ~/work/brain-os-plugin | {output} | commit:N/A | {result} | parent=ai-brain#{P} children={N} args="{input}"
action: engage (goal mode), task (task mode), issue (issue mode)output: goal mode → daily/grill-sessions/{session-file}; task/issue mode → ai-brain#{N}pass — work queued (settled+sliced / filed / relabeled) and all three spine checks greenpartial — work queued but spine degraded, or majority-HITL children, or trunk-gated to owner:humanfail — grill didn't settle, /slice aborted on its gates, or task draft rejectednpx claudepluginhub sonthanh/brain-os-pluginResumes unfinished work from previous handovers or directly claims GitHub issues via /pickup. Interactive flow when starting a new session.
Defines a goal with measurable success criteria and runs an autonomous plan-execute-validate loop until criteria are met or limits reached.
Prepares a GoalBuddy board for autonomous, long-running work: creates goal.md, state.yaml, and a structured task board for discovery, delegation, and execution. Use when work is broad, stalled, or needs a PM-owned rolling board.