/worktree

description: Worktree lifecycle management - create, list, remove, info on interactive worktrees
argument-hint: "[create <name|task-id> [--branch <ref>] [--attach|--new-branch] [--flow plan|plan-workflow] [--launch-mode default|auto|all-in] [--auto] [--all-in] [--orca|--cmux|--tmux]|create --team [<callsign>] --area <a> [--launch-mode default|auto|all-in] [--auto] [--all-in] [--orca|--cmux|--tmux]|list|info|remove <name>]"

Worktree Management

Thin dispatcher for interactive parallel worktrees. All filesystem/git work lives in the Go subcommand `lets worktree` (`cli/internal/worktreecmd/`); this skill captures user intent via `AskUserQuestion`, shells out with `--json`, and renders the result.

**Interactive worktrees only.** Agent worktrees (`isolation: worktree`) use native Claude Code behavior — not this command.

> **IMPORTANT:** If the spec below invokes any deferred tool (e.g. `AskUserQuestion`), you MUST load and call it as specified. Never skip the call, never substitute a default answer of your own — the tool invocation is part of the contract. This is critical.

Step 1: Determine Subcommand

**If argument provided** (e.g., `/lets:worktree create auth-feature`), parse it:

• `create --team [<callsign>] --area <a>` -> go to **Create a team** (a standing team's worktree and its lead). Strip `--team`, the optional `<callsign>`, `--area <a>`, the launcher overrides (`--orca` / `--no-orca` / `--cmux` / `--no-cmux` / `--tmux` / `--no-tmux`) and the launch-mode flags (`--launch-mode <m>` / `--auto` / `--all-in` - the lead's **Launch mode** below). **Refused** with one line, then stop: together with `--flow` (a team's lead starts interactively, on no flow), and from inside a worktree.
• `create <name>` -> go to Create. **First strip any `--orca` / `--no-orca` / `--cmux` / `--no-cmux` / `--tmux` / `--no-tmux` / `--launch-mode <m>` / `--auto` / `--all-in` / `--flow <value>` / `--branch <ref>` / `--title-file <path>` token** out of the argument and carry them as overrides (`--orca`/`--no-orca` = the Orca launcher, Step C0; `--cmux`/`--no-cmux`/`--tmux`/`--no-tmux` = launcher; `--launch-mode` / `--auto` / `--all-in` = the **Launch mode** below; `--flow plan|plan-workflow` = which command the launch lands in — all for Steps C0 / C3.5; `--branch <ref>` decouples the attached/created branch from the dir name — Step C2; `--title-file <path>` = a file holding the task title, passed by `take-task` so the branch name is derived in Go — Step C1). Bind the remainder as `<name>` (so `create auth --flow plan-workflow --auto` => name `auth`, not the flags; `create pwa-46696 --branch feature/pwa-46696` => name `pwa-46696`, branch `feature/pwa-46696`). A `<name>` that is a bare task id (it passes the detect-task id gate and `take-task` sent it) means **From task** in Step C1 with that id.
• `list` -> go to List
• `remove <name>` -> go to Remove
• `info` -> go to Info

**If no argument**, use **AskUserQuestion**:

AskUserQuestion(
  questions=[{
    question: "What do you want to do with worktrees?",
    header: "Action",
    options: [
      { label: "Create", description: "Create a new worktree for parallel work" },
      { label: "List", description: "Show all active worktrees" },
      { label: "Remove", description: "Remove a worktree and clean up" },
      { label: "Info", description: "Show current worktree status" }
    ],
    multiSelect: false
  }]
)

---

Create

Create an interactive worktree. The Go subcommand owns the guard, name validation, `.gitignore` ensure, `git worktree add`, symlinks (`.lets/` and the tracker adapter's declared store links), verify, and rollback. The skill drives the user choices.

Optional launcher override on the argument: `--orca` / `--no-orca` / `--cmux` / `--no-cmux` / `--tmux` / `--no-tmux` force the launcher for this run (otherwise `$LETS_LAUNCHER` decides — Orca in Step C0, the others in Step C3.5).

**Launch mode** (lets-d3wu3). How every session this command launches starts - `{launch_cmd}` below is `claude` rendered for it:

| mode | `{launch_cmd}` | |---|---| | `default` | `claude` | | `auto` | `claude --permission-mode auto` (auto-approves low-risk work; LETS AUTO MODE rules still gate push / PR / close / external) | | `all-in` | `claude --permission-mode bypassPermissions` (no harness permission prompts in that session) |

Resolve it once: a flag the user typed in this turn - `--launch-mode <m>`, `--auto` (= `auto`) or `--all-in` (= `all-in`) - beats `LETS_LAUNCH_MODE`, read through Go: `lets worktree info --json` -> `launch_mode` (`value`, `source` = `project` | `user` | `unset`, `valid`); neither set -> `default`. With no launch-mode flag typed in this turn, `launch_mode.valid=false` (a hand-edited value outside default | auto | all-in) -> `default`, plus one line "LETS_LAUNCH_MODE=<value> is not default | auto | all-in; launching in default"; with a typed flag the flag's mode applies and the invalid value is only named: "LETS_LAUNCH_MODE=<value> is not default | auto | all-in; ignored for the typed flag". The mode's **source** is the flag (`--all-in flag`, `--auto flag`, `--launch-mode flag`) or the file: `LETS_LAUNCH_MODE in .lets/.env` (`source=project`), `LETS_LAUNCH_MODE in ~/.lets/.env` (`source=user`). `all-in` is explicit only: such a flag, or `LETS_LAUNCH_MODE=all-in` the owner set - never inferred, never a fallback, never the default. Before EVERY `all-in` launch, print one line, then launch: "launching <name> with all-in (bypassPermissions; source: <source>): no harness permission prompts in that session; LETS gates (push, PR, merge, close, peer sends) still ask" (`<name>` = the session, slug or worktree being opened; `<source>` = the mode's source, or, for a team's lead on Reopen, the key T5 launches: `team file orca_agent` on the orca launcher, `team file agent_command` otherwise). The LETS gates are prompt discipline and are unchanged; `crossSessionInbound` is never written. The harness holds a cross-session messag