Advanced execution

Parallel worktrees, chained skills, and handing TTY-bound commands to your own shell.

Command	Arguments	What it does
`/aoforge:workstreams` type it yourself	`<setup\|status\|merge\|run> [args...]`	Run independent objectives in parallel using git worktrees, then merge results back.
`/aoforge:flow`	`<description of the multi-step flow>`	Orchestrate a multi-step AOForge workflow by chaining skills. Use when the user wants to invoke a sequence of skills as one ask (e.g., "build and sync to github", "research, plan, then build", "ship and announce").
`/aoforge:handoff`	`<command to run interactively or via user shell>`	Hand off a TTY-required or shell-env-dependent command to the user's shell.

/aoforge:workstreams

Runs independent objectives in parallel using git worktrees, then merges them back. This is a level above wave parallelism — waves parallelise jobs inside one objective; workstreams parallelise whole objectives.

/aoforge:workstreams setup      # provision worktrees for independent objectives
/aoforge:workstreams status     # what's running where
/aoforge:workstreams run        # execute across the workstreams
/aoforge:workstreams merge      # merge completed streams back

Configuration:

{
  "workstreams": {
    "worktree_prefix": "../{project}-ws-",
    "branch_prefix": "df/ws-",
    "merge_strategy": "squash"
  }
}

setup runs a dependency analysis first — objectives that touch the same modules are not eligible, because the merge would conflict. Under the hood:

aof-tools workstreams analyze     # which objectives can run independently
aof-tools workstreams provision   # create the worktrees and branches
aof-tools workstreams reconcile   # resolve state after merges

User-typed only, and genuinely advanced

/aoforge:workstreams carries disable-model-invocation: true. It creates and merges git worktrees, and a bad merge strategy across three concurrent streams is a real mess to unpick. Use it when you have several genuinely independent objectives and the wall-clock saving matters.

/aoforge:flow

Chains skills into one request.

/aoforge:flow build objective 4 then sync to github
/aoforge:flow research, plan, then build objective 6

It parses the described sequence and invokes each skill in order, passing state between them. Use it when you already know the sequence and would rather not type three commands and wait between each.

/aoforge:handoff

Hands a command that needs a TTY or your shell environment over to your actual shell.

/aoforge:handoff gh auth login
/aoforge:handoff mise install

Why this exists

Some commands cannot run in an agent’s non-interactive Bash: TTY-interactive auth (gh auth login, doctl auth init, aws sso login, op signin, npm login), password prompts, and shell-flow tools that depend on sourced rc files (nvm use, pyenv shell, conda activate, direnv allow, mise use, asdf shell).

Without a mechanism, Claude has to stop and ask you to paste ! cmd, which breaks both its flow and yours.

With the watcher running

aoforge-watch start --foreground   # in a terminal you keep open: the attended terminal
aoforge-watch status               # verify (from another terminal)

Now the gate-interactive hook intercepts those commands, queues them, and denies the Bash call; Claude tells you in one line that the command is waiting in your aoforge-watch terminal. The daemon runs it there and you answer its prompt there. The result comes back by itself: the inject-handoff-results hook delivers it to the session or subagent that queued it after its next tool call, or when Claude ends its turn, and the route-results hook delivers anything still waiting on your next prompt. Claude never asks you to paste anything.

Without the watcher

The handoff skill prints the command for you to run with ! cmd. Still useful — it recognises which commands need this and does not waste a turn failing first.

See the handoff guide for the daemon’s allowlist, auto-launch, multi-project watching and PTY support.