Let one Session hand work to another, and know when it landed.

Before you start

• Free and local. Everything here runs on one machine without a Clawdline Cloud account.
• macOS or Linux. Dispatch opens each child in a terminal: tmux, or iTerm2 on a Mac. On Windows it stops with no_child_capability; see Install.
• Only the machine dispatches. A paired browser or phone can read and type into Sessions, but cannot start a child.

Teach your Sessions: install the skill

Sessions learn the Clawdline commands from a skill. Nothing installs it for you. Run once per machine:

clawdline skill install
clawdline guide          # read the same guide your Sessions read

Expected result: Installed this build's stub at …, or Already installed when nothing changed. Sessions started afterwards load it. Undo: clawdline skill uninstall puts back the file that was there before.

Dispatch a child

The Session that dispatches is the root; the bounded task it starts is the child. You usually ask the root in plain words ("dispatch a child to add a test for the parser"), and it runs:

clawdline dispatch --title "Add a test for the parser" --claims internal/parser \
  --isolation worktree < brief.md

• --claims lists the paths the child may change, so two children do not collide.
• --isolation worktree gives the child its own Git worktree and branch. Without it, the child works in the project directory.
• Optional: --assistant claude|codex, --model, --permission-mode ask|edits|full (default full), --timeout in minutes (default 30, at most 240).

Expected result: the command prints dispatched <id> <state>. The child opens in its own terminal and appears under its root in the Session list, marked └. When it finishes, its result is typed into the root. clawdline task show <id> shows its state, summary, and what is left.

Wait for a long command with a callback

A build, test run, or deployment may keep a Session waiting after its decisions are done. The owning Session can ask Clawdline to run that command under the local daemon, then end its turn. When the command exits, Clawdline sends a completion notice and wakes that Session. It checks the task result before reporting success or failure. A callback starts no child Session, uses no child slot, and makes no claim that a Git change landed.

Ask the Session to use a callback for a command that needs no Agent decisions while it runs. The installed skill gives it the current syntax through clawdline guide callback. Expected result: one completion notice with the command exit status; the Session can inspect it with clawdline task show. A timeout or cancellation ends the task. Inspect a failed or uncertain result before retrying a command with side effects.

Landing: a finished child is not merged work

A child that finishes has delivered. Its work is not on your branch until the root merges it.

1. The root reviews the result with clawdline task show <id>.
2. The root merges the child's branch into the target branch.
3. Within a few minutes, Clawdline checks the merge in Git and records the work as landed by itself.

clawdline landings lists every landing still owed on the machine. A cherry-pick, or a task with nothing to land, is not detected; the root records it (clawdline guide landing explains how).

When a root Session finishes a turn, it records it as delivered and awaiting your review:

clawdline session report --summary "The parser test is in and passing"

Expected result: the Session's row shows it as delivered. A report claims no review and no landing. Sessions and states explains each mark.

Hand a line of work to a successor

When a Session is too full or should stop, it can hand its whole line of work to a new Session instead of dispatching a child. It writes a handoff note with three parts: what the successor must read, questions it answers before continuing, and where to pick up. Clawdline opens the successor with the note and tells the sender when it has picked up. A handoff moves ownership; a child does not.

Clawdfather: the machine's own Session

Clawdfather looks after the machine, not a project. It inspects Sessions, reports what is known and unknown, and changes the machine settings Clawdline exposes. It does not edit any project's code: when you ask it to arrange engineering work, it creates a Board item in that project and assigns it to a project Session, which owns the work from there.

1. In the Session list, open the machine-load panel from the Session counts.
2. Choose 開啟 Clawdfather (Open Clawdfather). If one exists, this opens it.
3. To register it as the machine coordinator, ask it to run clawdline coordinator bind after its first message.

Start a Session as a role

A role is a written definition, such as Architect, Code Reviewer, or Technical Writer, that shapes how a Session works. It never overrides your project's CLAUDE.md or AGENTS.md.

1. Open 角色小隊 (Squad) in the menu to browse teams and each role's full definition.
2. When you start a Session, pick one under 角色 (Role). The default is 不指定 (no role). The role stays for the whole conversation.
3. In a role's detail, write a 角色手冊 (role handbook) for all projects or for one, and turn its skills on or off.
4. Use 讀入資料包 (import pack) or 匯出資料包 (export pack) to move roles and skills as a ZIP of at most 512 KiB. Import shows the source, licence, and conflicts first; export leaves private settings out by default.

Expected result: changes apply to Sessions started afterwards; a running Session keeps its role text.

Where to go deeper

• Board and plans — track larger work as items that a Session moves to done.
• Schedules and webhooks — start a Session on a clock or from another service.
• Clawdfather and dispatch — the product repository's guide.
• docs/personas.md — every built-in role.