Clawdline

This file is a pointer, not the guide. The guide is compiled into the clawdline binary, so the one you read is always the one written for the daemon that will answer you. Routes, fields and refusals are deliberately not repeated here: a copy of them goes stale against the build.

Load the guide first

Find the binary once, in this order, and use the first that exists:

1. $CLAWDLINE_SKILL_READER, if it is set.
2. $CLAWDLINE_NEXT_DIR/bin/clawdline, if CLAWDLINE_NEXT_DIR is set; otherwise ~/.config/clawdline-next/bin/clawdline ($XDG_CONFIG_HOME/clawdline-next/bin/clawdline when XDG_CONFIG_HOME is set; %APPDATA%\clawdline-next\bin\clawdline.exe on Windows). The daemon keeps an up-to-date copy of itself there every time it starts.
3. /Applications/Clawdline Next.app/Contents/MacOS/clawdline, then the same under ~/Applications.

Call it BIN below, and substitute the real path; do not run BIN literally.

BIN guide              # the core every session needs, and a list of the other parts
BIN guide dispatch     # one part, when the work in front of you needs it
BIN guide all          # the whole guide
BIN guide zh-Hant      # Taiwan Traditional Chinese; zh-TW remains an alias
BIN guide -sections    # the names of the parts

Reading the guide is a local read: it needs no running daemon and no network. Read the core before you run anything else, then print a part when you reach work it covers — not the whole guide up front: everything you read stays in your context and is re-read on every later call. Do not guess routes or fields from memory, from an older guide, or from the Swift app's bundle — that app's routes are not this daemon's.

If the path you chose exists and fails, report its exact error and stop. Do not fall through to the next path: another binary may be a different build from the daemon that will answer you. If none of the paths exists, Clawdline Next is not installed here; say so rather than inventing routes.

Manage Playbooks

When asked to create, edit, list or delete a saved Playbook, print BIN guide project. It describes the CLI and the existing reusable-text API, including Project resolution and safe retries. Saving a definition does not start it or send its message.

Unify a Project's rules and skills

When invoked as /clawdline unify, or asked to make one Project's Claude and Codex sessions share the same rules and skills, print BIN guide project and follow its Unify part exactly: show the plan from clawdline project unify, apply it only after the person's message in this conversation approves it, and never edit AGENTS.md, CLAUDE.md or a skill to resolve a conflict yourself.

Roles

Which kind of work goes where is a boundary, not a routing detail; the guide names the route for each.

• Owned child: a bounded task under this session, which keeps synthesis, integration and landing.
• Handoff: continuing or transferring an existing line of work, with its full state.
• Detached automation: unattended work with no root. Never a Root or a feature owner.
• Root assignment: a new, independently owned Root for a new feature. Never faked with a child, a detached task or a handoff.

A Feature Root — a Root assignment, or a Session given a Board item — prints BIN guide feature-root: its whole ordinary path, from reading the item to done. It works in the owning Session by default and dispatches only for a concrete need.

A Clawdline child does not dispatch and does not send a turn receipt; it reports through the result.json its briefing describes.