wt-switch-create
The `wt-switch-create` skill creates a new git worktree with a specified branch name, optionally in a different repository, and switches the session's working directory into it. Use this when starting a session that should operate in an isolated branch context or mid-session when work needs to move into a fresh worktree, such as `/wt-switch-create my-feature -- fix the parser bug`.
git clone --depth 1 https://github.com/max-sixty/worktrunk /tmp/wt-switch-create && cp -r /tmp/wt-switch-create/skills/wt-switch-create ~/.claude/skills/wt-switch-createSKILL.md
Arguments: `$ARGUMENTS`. Grammar: `[<branch>] [<repo>] [-- <task>]`.
- **branch** — optional; the branch name for the new worktree. When omitted,
pick one (step 1 below).
- **repo** — optional path; create the worktree in this repo instead of the
session's current one.
- **task** — optional; what to do inside the new worktree. No task means enter
the worktree and wait.
Tokens before the `--` are the branch and/or repo: a path-shaped token
(starting with `/`, `~`, `./`, or `../`) is the repo; any other token is the
branch (`docs` is a branch name, never the `docs/` directory). More than one
branch-shaped token before a `--` doesn't fit the grammar — ask. Without a
`--`, judge where the task starts: leading tokens that read as a branch name
(`fix-auth`) or a repo path are consumed as such, and the rest is the task;
otherwise the whole input is the task (`fix the parser bug` has no
branch-shaped lead — all task).
```
/wt-switch-create my-feature -- fix the parser bug
/wt-switch-create -- fix the parser bug
/wt-switch-create my-feature ~/workspace/other-repo -- fix the parser bug
/wt-switch-create my-feature
```
## What to do
Steps 1–3 come before any other work.
<!-- Maintainers: rationale.md (same directory) covers the harness rules and
design choices behind this — read it before re-adding guards or routes. -->
1. **Pick the branch name** if none was given: short, from the task and
consistent with existing worktree names, or, mid-session, from the work
being moved; with nothing to derive from, ask.
2. **Create the worktree** with a `Bash` call (omit `-C <repo>` for this repo):
```
wt -C <repo> switch --create <branch> --no-cd --format=json
```
Stdout is JSON whose `path` field is the worktree's absolute path (status
lines go to stderr). On `Branch <branch> already exists`: if the user named
the branch, rerun without `--create` (it enters the branch, creating its
worktree if missing); if step 1 picked the name, pick another and rerun. Any
other failure (not a git repo, invalid name): report it and stop.
Mid-session, carry uncommitted work across: `git stash push -u` before
creating the worktree, then `git -C <path> stash pop` after (the stash is
shared across worktrees).
3. **Enter the worktree, then do the task.** Call
`EnterWorktree({path: "<path from the JSON>"})`.
- **Accepted** → the session is re-rooted in the worktree. Do the task (or,
with no task text, confirm it's ready and wait).
- **Rejected** → graceful, and nothing is created. `EnterWorktree`
re-roots only into a worktree the session is permitted to enter, and that
permitted set is fixed by two factors: the repo your cwd resolves to, and
the session's state. Each rejection is just that set coming up empty or
without the target: no repo resolves (cwd is outside any git repo, e.g. a
non-git parent such as `~/workspace` that only holds repos, as in a
background job), which fails with `the current directory is not in a git
repository`; the target belongs to a different repo than the one resolved;
or the session is already rooted in a worktree (or is a pinned agent), a
state that narrows the set to the resolved repo's `.claude/worktrees/` and
so excludes even a same-repo `wt` sibling. All reduce to the same recovery
test: whether you can `cd` into the worktree, which works when it's inside
an allowed directory (a `permissions.additionalDirectories` entry such as
`~/workspace`). So `cd <path>` and read the result:
- no `Shell cwd was reset` notice → it stuck; the worktree is reachable.
Work there, but a bare `cd` is not a tracked re-root, so the cwd can
revert to the session's launch worktree across turns (and in spawned
subagents); pin commands with `git -C <path>` / `wt -C <path>` rather
than trusting the `cd` to persist.
- `Shell cwd was reset` → not reachable. Stop and ask the user to make it
reachable: add the repo, or a parent like `~/workspace`, to
`permissions.additionalDirectories` (durable, every session), or run
`/add-dir <path>` (this session). Then continue. Don't grind through
absolute paths with `cd` resetting on every command.
## Cleanup
The worktree is a normal worktrunk worktree: it persists after the session
ends, shows up in `wt list`, and is merged or removed with `wt merge` /
`wt remove <branch>` like any other. Don't remove it unprompted. If the user
asks to leave mid-session, `ExitWorktree({action: "keep"})` returns the
session to its original directory; `ExitWorktree` cannot remove a worktree
entered by `path`, so removal is always `wt remove <branch>`.
## Scope
This command authorizes creating/entering ONE worktree (in the named repo, if
one was given) and doing the requested task. Commits, pushes, and merges still
each require explicit user permission.Worktrunk release workflow. Use when user asks to "do a release", "release a new version", "cut a release", or wants to publish a new version to crates.io and GitHub.
Worktrunk-specific guidance for tend CI workflows. Adds codecov polling, Rust test commands, labels, and review criteria on top of the generic tend-* skills. Use when operating in CI.
CLI output formatting standards for worktrunk. Load before editing any code that calls warning_message, hint_message, error_message, info_message, eprintln, or println, or that produces strings the user will see (CLI help, progress UI, snapshot text). Documents ANSI color nesting rules, message patterns, and output system architecture.
Guidance for Worktrunk (the `wt` CLI) — git worktree management, hooks, and config. Load when editing .config/wt.toml or ~/.config/worktrunk/config.toml; adding, modifying, or debugging hooks (post-merge, post-start, pre-commit, pre-merge, post-switch, etc.); configuring commit message generation or command aliases; or troubleshooting wt behavior. Also answers general worktrunk/wt questions.