Ce Worktree
Spin an isolated git worktree with env files and tool trust so parallel features or PR review do not touch your main checkout.
Overview
ce-worktree is an agent skill most often used in Build (also Ship) that creates isolated git worktrees with env copy and mise/direnv trust rules for parallel features or PR review.
Install
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-worktreeWhat is this skill?
- Creates worktrees under .worktrees/<branch> via bundled worktree-manager.sh
- Copies .env, .env.local, .env.test from main repo while skipping .env.example
- Branch-aware mise/direnv trust so review branches do not auto-trust risky .envrc
- Ensures .worktrees is gitignored and does not check out from-branch on main repo
- Intended companion to ce-work and ce-code-review worktree options
- Copies .env, .env.local, .env.test and skips .env.example
- Worktrees live under .worktrees/<branch-name>
Adoption & trust: 1.5k installs on skills.sh; 20.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want parallel branch work or PR review in a clean tree but copying env files and trusting direnv safely is tedious and error-prone with plain git worktree add.
Who is it for?
Compound Engineering users on git repos who parallelize features or accept worktree options from ce-work and ce-code-review.
Skip if: Repos without git, builders who only need a single-branch workflow, or environments where Bash worktree scripts are disallowed.
When should I use this skill?
Starting parallel feature work or PR review that should not disturb the current checkout, or when ce-work or ce-code-review offers a worktree option.
What do I get? / Deliverables
You get a ready worktree path with env parity and ignore rules so ce-work or review flows can run without disturbing your main checkout.
- New worktree directory under .worktrees/<branch>
- Updated .gitignore entry for .worktrees when missing
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Build pm is where solo builders parallelize branches and context-switch without stashing half-finished work on main. Pm covers orchestrating multiple workstreams; worktrees are the git primitive for that isolation beyond a single active branch.
Where it fits
Create a worktree for feature/oauth while keeping main on your current sprint branch.
Isolate agent edits for a risky dependency bump in .worktrees/bump-deps without touching local runtime on main.
Accept ce-code-review’s worktree path to review a contributor PR with copied .env.test for running checks.
How it compares
Opinionated worktree bootstrap with env and direnv handling—not a full monorepo dev environment manager or cloud preview URL.
Common Questions / FAQ
Who is ce-worktree for?
Solo and indie devs using the compound-engineering plugin who need isolated trees for parallel coding or review-driven workflows.
When should I use ce-worktree?
At Build pm when starting parallel feature branches, or at Ship review when ce-code-review offers a worktree option before you diff or fix a PR.
Is ce-worktree safe to install?
It runs Bash against your repo and copies env files; review the Security Audits panel on this page and inspect .envrc trust behavior on untrusted review branches.
SKILL.md
READMESKILL.md - Ce Worktree
# Worktree Creation Create a worktree under `.worktrees/<branch>` with branch-specific setup that `git worktree add` alone does not handle: - Copies `.env`, `.env.local`, `.env.test`, etc. from the main repo (skips `.env.example`) - Trusts `mise`/`direnv` configs, with branch-aware safety rules so review branches do not auto-grant trust to untrusted `.envrc` content - Adds `.worktrees` to `.gitignore` if not already ignored - Does not modify the main repo checkout — `from-branch` is fetched, not checked out ## Creating a worktree Invoke the bundled script via the runtime Bash tool. On Claude Code, `${CLAUDE_SKILL_DIR}` resolves to the skill's own directory across both marketplace-cached installs and `claude --plugin-dir` local development; the runtime Bash tool's CWD is the user's project, not the skill directory, so a bare `bash scripts/worktree-manager.sh` fails. On other targets (Codex, Gemini, Pi, etc.) `${CLAUDE_SKILL_DIR}` is unset and the `:-.` fallback yields the bare relative path those harnesses expect. ```bash bash "${CLAUDE_SKILL_DIR:-.}/scripts/worktree-manager.sh" create <branch-name> [from-branch] ``` Defaults: - `from-branch` defaults to origin's default branch (or `main` if that cannot be resolved) - The new branch is created at `origin/<from-branch>` (or the local ref if the remote is unavailable) Examples: ```bash bash "${CLAUDE_SKILL_DIR:-.}/scripts/worktree-manager.sh" create feat/login bash "${CLAUDE_SKILL_DIR:-.}/scripts/worktree-manager.sh" create fix/email-validation develop ``` After creation, switch to the worktree with `cd .worktrees/<branch-name>`. ## Other worktree operations Use `git` directly — no wrapper is needed and none is provided: ```bash git worktree list # list worktrees git worktree remove .worktrees/<branch> # remove a worktree cd .worktrees/<branch> # switch to a worktree cd "$(git rev-parse --show-toplevel)" # return to main checkout ``` To copy `.env*` files into an existing worktree created without them, run this from the main repo (not from inside the worktree, since branch names often contain slashes like `feat/login`): ```bash cp .env* .worktrees/<branch>/ ``` ## Dev tool trust behavior When mise or direnv configs are present, the script attempts to trust them so hooks and scripts do not block on interactive prompts. Trust is baseline-checked against a reference branch: - **Trusted base branches** (`main`, `develop`, `dev`, `trunk`, `staging`, `release/*`): the new worktree's configs are compared against that branch; unchanged configs are auto-trusted. `direnv allow` is permitted. - **Other branches** (feature branches, PR review branches): configs are compared against the default branch; `direnv allow` is skipped regardless, because `.envrc` can source files that direnv does not validate. Modified configs are never auto-trusted. The script prints the manual trust command to run after review. ## When to create a worktree Create a worktree when: - Reviewing a PR while keeping the main checkout free for other work - Running multiple features in parallel without branch-switching overhead - Keeping the default branch free of in-progress state Do not create a worktree for single-task work that can happen on a branch in the main checkout. ## Integration `ce-work` and `ce-code-review` offer this skill as an option. When the user selects "worktree" in those flows, invoke `bash "${CLAUDE_SKILL_DIR:-.}/scripts/worktree-manager.sh" create <branch>` with a meaningful branch name derived from the work description (e.g., `feat/crowd-sniff`, `fix/email-validation`). Avoid auto-generated names like `worktree-jolly-beaming-raven` that o