메뉴
Creates or removes a git worktree with automatic .env copy and dependency installation. Usage: /worktree <branch-name> | /worktree remove <branch-name>
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| 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.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.