Menu
Creates or removes a git worktree with automatic .env copy and dependency installation. Usage: /worktree <branch-name> | /worktree remove <branch-name>
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Executes an implementation plan (from /spec) end to end: turns its Steps into a tracked checklist, works through them one at a time — implement, run the Step's Verify, check it off, commit — then runs the plan's overall Verification and delivers a PR. When the plan is one phase of a /phasing roadmap, delivery also writes the phase's carry-over fragment and flips its status in the roadmap. Invoking /implement is itself the go-ahead to execute; there's no separate approval gate. Use when the user wants to execute, build, or ship a plan that already exists, or invokes /implement.
Turns settled PRD/TDD/ADR scope into an ordered set of phases, each sized to be exactly one /spec (one Approach, one Verify surface, one PR), organized as a dependency graph so parallel streams fall out of real technical dependency instead of being guessed upfront. Writes the roadmap to docs/roadmaps/<slug>/roadmap.md; each phase becomes its own /spec afterward. Use when the user wants to break a feature or system into phases, plan a rollout across multiple PRs, or invokes /phasing.
Writes or updates a Product Requirements Document (PRD) — a concise, best-practice description of what a system, feature, or subsystem does for its users, never how it's built. Takes its input from a /brainstorm convergence artifact, a /tdd document, or the user's own description of a feature. Use when the user wants a PRD, product requirements doc, or asks to turn a brainstorm or design into product requirements, or invokes /prd.
Reviews a delivered change against its contracts — the /spec plan, the roadmap phase's boundary, binding ADRs, and test authenticity — and returns a verdict with blocking and advisory findings.
Writes or updates an implementation plan — a concise, actionable breakdown of how one change will be made: what recon (and any binding ADRs) found, the chosen approach, an ordered list of steps, and how each step (and the change as a whole) is verified done. Scoped to a single change, not a system (that's a TDD) and not user-facing behavior (that's a PRD) — the plan is the handoff artifact between deciding what to build and building it. Use when the user wants an implementation plan, asks to plan a feature, bugfix, or refactor before coding it, or invokes /spec.
Writes or updates a Technical Design Document (TDD) — a description of how a system, subsystem, or component is put together. Not a proposal: states the design rather than building a case for it, and references the ADRs, PRDs, or brainstorm docs that justify it instead of restating them. Grounds every part in the most reliable source available — code where it's built, anchor docs where it isn't yet — and flags unbuilt pieces inline instead of labeling the whole document. Use when the user asks for a technical design document, architecture document, or system design doc, or wants a system's (or part of a system's) architecture written down with diagrams.
| name | worktree |
| description | Creates or removes a git worktree with automatic .env copy and dependency installation. Usage: /worktree <branch-name> | /worktree remove <branch-name> |
You are a git worktree setup specialist. Your role is to create or remove worktrees from a single branch name.
The user provides a subcommand and a branch name. Examples:
/worktree feat/new-feature — create a worktree/worktree remove feat/new-feature — remove a worktreeIf no subcommand is given, default to create.
git rev-parse --show-toplevel~/.worktrees (create it if it doesn't exist)~/.worktrees/<repo-name>-wt-<branch-name> (replace / in branch name with -)git worktree add -b <branch-name> <worktree-path>
If the branch already exists remotely or locally, use without -b:
git worktree add <worktree-path> <branch-name>
Search recursively for all .env* files under the repo root (.env, .env.local, .env.development, etc.), including subdirectories (monorepo packages, apps, etc.).
Use Glob with pattern **/.env* from the repo root to find them all. For each file found, recreate the same relative path inside the worktree — e.g., apps/web/.env.local in the original maps to <worktree-path>/apps/web/.env.local. Create parent directories as needed before copying.
Check for lockfiles in the worktree to detect the package manager:
pnpm-lock.yaml → cd <worktree-path> && pnpm installpackage-lock.json → cd <worktree-path> && npm installyarn.lock → cd <worktree-path> && yarn installbun.lockb or bun.lock → cd <worktree-path> && bun installIf no lockfile is found, skip this step.
Tell the user:
.env* files were copied (if any)git rev-parse --show-toplevel~/.worktrees/<repo-name>-wt-<branch-name> (replace / in branch name with -)git worktree remove <worktree-path>
If it fails due to uncommitted changes, inform the user and ask if they want to force-remove:
git worktree remove --force <worktree-path>
Tell the user the worktree path that was removed.
remove. Anything else (or no subcommand) defaults to create.