git-worktree

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

@rules/worktree-lifecycle.md @references/source-survey.md

Git Worktree Skill

Git Worktree 技能

Make isolated branch workspaces cheap, visible, and safe.

Create and manage Git worktrees under the project convention:
```
.hypercore/git-worktree/<folder_name>
```
.
Support parallel feature work, agent sessions, reviews, hotfixes, and experiments without branch-switching churn.
Keep worktree operations safe by asking for missing task intent before creation, checking status before removal, resolving the current linked worktree when no path is given, using explicit paths, and validating Git’s worktree registry.
Match the user's language for any clarification question. For Korean prompts, ask in Korean; do not show an English operation menu.

</purpose>

<routing_rule>

Use

git-worktree

when the user wants to:

create a worktree, workspace, branch folder, or isolated checkout
run multiple coding agents or tasks in parallel without file conflicts
list, open, switch to, remove, prune, repair, lock, or unlock worktrees
delete the current linked worktree when the user is already inside it and says things like "remove/delete this worktree" or "delete worktree"
standardize worktree folders under
```
.hypercore/git-worktree/<folder_name>
```
review or test a branch/PR/issue in a separate local directory

Do not use

git-worktree

when:

the user only asks for normal branch creation or checkout in the current folder
the user asks for history rewriting, rebase strategy, or commit grouping without a worktree operation
the requested isolation must be a container, VM, or separate clone rather than a Git worktree

</routing_rule>

<activation_examples>

Positive requests:

"Create a worktree for
```
feature/auth
```
and open Codex there."
"
```
git-worktree fix/api-timeout
```
"
"Create this branch as a worktree under
```
.hypercore/git-worktree
```
."
"Spin up three isolated worktrees for parallel agents."
"Create a new worktree and move me into it."
"List my active git worktrees and remove the stale ones safely."
"I'm already in this worktree; delete this worktree safely."
"I am already inside this worktree; delete the worktree safely."
"Set up PR #42 for review in a separate worktree."

Negative requests:

"Create a new branch here and checkout it." Use normal Git branch workflow.
"Explain what Git worktree means." Answer directly unless an actionable worktree operation is requested.
"Make a Docker dev environment for each branch." Use a container/dev-env workflow instead.

Boundary request:

"Set up an isolated workspace for this risky refactor." Use this skill if Git branch isolation is enough; escalate to a container/VM workflow only if runtime, database, port, or dependency isolation is required.

</activation_examples>

<trigger_conditions>

User intent	Activate
Create a branch-specific working directory	yes
Parallel AI agent/coding sessions on one repo	yes
List or open existing worktrees	yes
Remove, prune, lock, unlock, repair, or move worktrees	yes
Delete the current linked worktree from inside that worktree	yes
Configure project default worktree root	yes
Plain `git checkout` or branch-only operations	no
General Git tutorial with no operation	no

</trigger_conditions>

<argument_handling>

If the user invokes
```
git-worktree <ARGUMENT>
```
or supplies one positional argument after the skill name, treat
```
<ARGUMENT>
```
as an explicit create target and do not ask what worktree to create.
Interpret
```
<ARGUMENT>
```
as the branch/task label unless it is clearly a PR/issue/ref/path; preserve the branch/ref text and sanitize only the folder label.
Use
```
.hypercore/git-worktree/<folder_name>
```
, then move the active agent context into the new worktree.
Ask only if the argument is unsafe, reserved, conflicts with an unrelated path, or cannot map to a Git ref/branch/task label.

</argument_handling>

Canonical root:
```
<repo-root>/.hypercore/git-worktree/
```
.

Canonical path:

<repo-root>/.hypercore/git-worktree/<folder_name>

Default
```
<folder_name>
```
: ask what work will happen in the worktree when the user has not already supplied a clear task, then derive a concise sanitized slug from that answer.
If the user already supplied a positional argument, branch, PR, issue, or task name, derive
```
<folder_name>
```
from that context without asking again.
Clarification language: infer the operation from the request whenever possible. If an operation is truly ambiguous, ask one short question in the user's language. For Korean users, ask which worktree operation they want, such as create, list, open/move, delete, clean up, repair, lock, or unlock. Never ask a generic English operation menu.
After creating a worktree, creation is not complete until the active execution context has moved into that folder: in a persistent shell/session, actually execute
```
cd <path>
```
there; in tool-only environments, set the next command's
```
workdir=<path>
```
and keep subsequent commands there. Do not merely display
```
cd <path>
```
as the final answer.
If removal is requested without a path and the active context is already inside a linked worktree, treat the current worktree root as the removal target, move out to a safe worktree before removal, and never remove the main worktree.
Add or verify a local ignore/exclude for
```
.hypercore/git-worktree/
```
before creating nested worktrees.
Prefer native
```
git worktree
```
commands over installing extra managers.
Prefer one task, branch, terminal session, and editor window per worktree.

</defaults>

<supported_operations>

Create a worktree from a new branch, existing local branch, remote branch, PR ref, issue task, or commit.
Enter/open a worktree in the shell, editor, tmux session, or agent CLI when available.
List worktrees with branch, path, dirty/clean status, lock/prunable annotations, and next action.
Remove completed worktrees after verifying committed or intentionally discarded changes.
Remove the current linked worktree even when the request is made from inside it, by resolving the current top-level path first and executing
```
git worktree remove
```
from another safe worktree.
Prune stale metadata with a dry run first.
Repair moved worktrees and lock long-lived worktrees when accidental pruning would be harmful.

</supported_operations>

让隔离分支工作区更低成本、可见且安全。

按照项目约定在
```
.hypercore/git-worktree/<folder_name>
```
下创建和管理Git工作树。
支持并行特性开发、Agent会话、代码评审、热修复和实验，无需频繁切换分支。
通过在创建前询问缺失的任务意图、移除前检查状态、无路径时解析当前关联工作树、使用明确路径以及验证Git工作树注册表，确保工作树操作的安全性。
任何澄清问题都使用用户的语言。对于韩语请求，用韩语提问；不要显示英文操作菜单。

</purpose>

<routing_rule>

当用户需要以下操作时使用

git-worktree

：

创建工作树、工作区、分支文件夹或隔离检出环境
并行运行多个编码Agent或任务，避免文件冲突
列出、打开、切换至、移除、清理、修复、锁定或解锁工作树
当用户已在某个工作树内并说出诸如“移除/删除此工作树”或“删除工作树”的指令时，删除当前关联的工作树
将工作树文件夹标准化至
```
.hypercore/git-worktree/<folder_name>
```
下
在单独的本地目录中评审或测试分支/PR/议题

以下情况不使用

git-worktree

：

用户仅要求在当前文件夹中创建或检出普通分支
用户询问历史重写、变基策略或提交分组，且未涉及工作树操作
用户要求的隔离环境必须是容器、虚拟机或独立克隆，而非Git工作树

</routing_rule>

<activation_examples>

正向请求示例：

"为
```
feature/auth
```
创建一个工作树并在其中打开Codex。"
"
```
git-worktree fix/api-timeout
```
"
"将此分支创建为
```
.hypercore/git-worktree
```
下的工作树。"
"创建三个隔离工作树用于并行Agent会话。"
"创建一个新工作树并切换至其中。"
"列出我当前的git工作树并安全移除已过期的树。"
"我已经在这个工作树里了；安全删除此工作树。"
"我已经在这个工作树内；安全删除该工作树。"
"在单独的工作树中设置PR #42以供评审。"

负向请求示例：

"在这里创建一个新分支并检出它。" 使用普通Git分支工作流。
"解释Git worktree是什么意思。" 直接回答，除非用户请求可执行的工作树操作。
"为每个分支创建Docker开发环境。" 使用容器/开发环境工作流替代。

边界请求示例：

"为这个高风险重构设置隔离工作区。" 如果Git分支隔离足够，则使用本技能；仅当需要运行时、数据库、端口或依赖项隔离时，才升级到容器/虚拟机工作流。

</activation_examples>

<trigger_conditions>

用户意图	是否激活
创建分支专属工作目录	是
在单个仓库上并行运行AI Agent/编码会话	是
列出或打开现有工作树	是
移除、清理、锁定、解锁、修复或移动工作树	是
在工作树内删除当前关联的工作树	是
配置项目默认工作树根目录	是
普通 `git checkout` 或仅分支操作	否
无操作的通用Git教程	否

</trigger_conditions>

<argument_handling>

如果用户调用
```
git-worktree <ARGUMENT>
```
或在技能名称后提供一个位置参数，将
```
<ARGUMENT>
```
视为明确的创建目标，无需询问要创建哪个工作树。
将
```
<ARGUMENT>
```
视为分支/任务标签，除非它明显是PR/议题/引用/路径；保留分支/引用文本，仅清理文件夹标签。
使用
```
.hypercore/git-worktree/<folder_name>
```
路径，然后将活动Agent上下文转移至新工作树。
仅当参数不安全、为保留字、与无关路径冲突或无法映射到Git引用/分支/任务标签时，才进行询问。

</argument_handling>

标准根目录：
```
<repo-root>/.hypercore/git-worktree/
```
。

标准路径：

<repo-root>/.hypercore/git-worktree/<folder_name>

。

默认
```
<folder_name>
```
：当用户未提供明确任务时，询问将在工作树中进行的工作，然后从回答中推导简洁的清理后的标识符。
如果用户已提供位置参数、分支、PR、议题或任务名称，直接从该上下文推导
```
<folder_name>
```
，无需再次询问。
澄清语言：尽可能从请求中推断操作。如果操作确实不明确，用用户的语言提出一个简短问题。对于韩语用户，询问他们需要哪种工作树操作，例如创建、列出、打开/移动、删除、清理、修复、锁定或解锁。绝不要显示通用英文操作菜单。
创建工作树后，只有当活动执行上下文转移到该文件夹时，创建才算完成：在持久化shell/会话中，实际执行
```
cd <path>
```
；在仅工具环境中，设置下一个命令的
```
workdir=<path>
```
并将后续命令保持在该路径下。不要仅将
```
cd <path>
```
作为最终答案显示。
如果请求移除但未提供路径，且活动上下文已在关联工作树内，则将当前工作树根目录视为移除目标，在移除前转移到安全工作树，且绝不要移除主工作树。
创建嵌套工作树前，添加或验证针对
```
.hypercore/git-worktree/
```
的本地忽略/排除规则。
优先使用原生
```
git worktree
```
命令，而非安装额外的管理器。
优先为每个工作树分配一个任务、分支、终端会话和编辑器窗口。

</defaults>

<supported_operations>

从新分支、现有本地分支、远程分支、PR引用、议题任务或提交创建工作树。
在shell、编辑器、tmux会话或Agent CLI中打开/进入工作树（如果可用）。
列出工作树，包含分支、路径、脏/干净状态、锁定/可清理注释以及下一步操作。
在验证已提交或有意丢弃的更改后，移除已完成的工作树。
即使请求是在工作树内发出的，也能移除当前关联的工作树：先解析当前顶级路径，然后从另一个安全工作树执行
```
git worktree remove
```
。
先执行试运行，再清理过期元数据。
修复已移动的工作树，并在意外清理会造成危害时锁定长期存在的工作树。

</supported_operations>

Phase 1. Inspect repository and intent

阶段1. 检查仓库和意图

Confirm the current directory is inside a Git repository.
Resolve the repository root with
```
git rev-parse --show-toplevel
```
.
Read existing worktrees with
```
git worktree list --porcelain
```
.
Identify the requested operation: create, open, list, remove, prune, repair, lock, or unlock.
For removal with no explicit path, if the current directory is inside a linked worktree, select the current worktree root as the target; if it is the main worktree, stop and ask for a specific target instead of deleting the repository root.
If a
```
git-worktree <ARGUMENT>
```
argument is present, treat it as a create target and derive branch name, folder name, and base reference from it before any clarification.
Otherwise derive branch name, folder name, and base reference from user wording or current branch.
If creating and the task/folder intent is missing or too vague, ask one concise question before creation in the user's language. For Korean users, ask what work they plan to do in this worktree.
If the operation itself is unclear, avoid a generic English menu. Ask one localized question only after inference fails.

确认当前目录在Git仓库内。
使用
```
git rev-parse --show-toplevel
```
解析仓库根目录。
使用
```
git worktree list --porcelain
```
读取现有工作树。
识别请求的操作：创建、打开、列出、移除、清理、修复、锁定或解锁。
对于未提供明确路径的移除请求，如果当前目录在关联工作树内，则选择当前工作树根目录作为目标；如果是主工作树，则停止并询问具体目标，而非删除仓库根目录。
如果存在
```
git-worktree <ARGUMENT>
```
参数，将其视为创建目标，在任何澄清前推导分支名称、文件夹名称和基础引用。
否则，从用户措辞或当前分支推导分支名称、文件夹名称和基础引用。
如果是创建操作且任务/文件夹意图缺失或过于模糊，在创建前用用户的语言提出一个简洁的问题。对于韩语用户，询问他们计划在该工作树中进行什么工作。
如果操作本身不明确，避免使用通用英文菜单。仅在推断失败后，提出一个本地化问题。

Phase 2. Apply the project path convention

阶段2. 应用项目路径约定

Use

.hypercore/git-worktree/<folder_name>

as the default target path unless the user explicitly provides another path. Choose

<folder_name>

from the stated work intent, not from an arbitrary timestamp.

Before creating the worktree:

create the parent directory if needed
derive and sanitize
```
<folder_name>
```
from the stated work intent before path construction
verify the target path does not already contain unrelated files
ensure
```
.hypercore/git-worktree/
```
is ignored or locally excluded so the main worktree does not treat nested worktrees as normal untracked content
avoid reusing a branch already checked out by another worktree unless the operation is only to open/list it

除非用户明确提供其他路径，否则使用

.hypercore/git-worktree/<folder_name>

作为默认目标路径。根据指定的工作意图选择

<folder_name>

，而非任意时间戳。

创建工作树前：

如有需要，创建父目录
在构建路径前，从指定的工作意图推导并清理
```
<folder_name>
```
验证目标路径尚未包含无关文件
确保
```
.hypercore/git-worktree/
```
被忽略或本地排除，使主工作树不会将嵌套工作树视为普通未跟踪内容
避免复用已被其他工作树检出的分支，除非操作仅为打开/列出该分支

Phase 3. Execute the worktree operation

阶段3. 执行工作树操作

@rules/worktree-lifecycle.md

for command patterns, safety checks, and cleanup rules.

Creation preference:

Existing local branch:
```
git worktree add <path> <branch>
```
.
Existing remote branch: create a tracking/local branch if needed, then add the worktree.

New task branch:

git worktree add -b <branch> <path> <base-ref>

Detached inspection: use
```
--detach
```
only when the user is reviewing a commit and does not intend to commit changes.

Current-worktree removal preference:

When the user says to delete/remove the worktree while already inside a linked worktree, infer the target from
```
git rev-parse --show-toplevel
```
.

Confirm it is not the main worktree by comparing

git rev-parse --git-dir

and

git rev-parse --git-common-dir

and by reading

git worktree list --porcelain

Check status from the target path, save the target path, move execution to the main/safe worktree, then run
```
git worktree remove <target-path>
```
.
Use
```
--force
```
only when the user explicitly requested force/discard semantics or has confirmed dirty changes are disposable.

遵循

@rules/worktree-lifecycle.md

中的命令模式、安全检查和清理规则。

创建优先级：

现有本地分支：
```
git worktree add <path> <branch>
```
。
现有远程分支：如有需要，创建跟踪/本地分支，然后添加工作树。

新任务分支：

git worktree add -b <branch> <path> <base-ref>

。

分离式检查：仅当用户评审提交且无意提交更改时使用
```
--detach
```
。

当前工作树移除优先级：

当用户在关联工作树内说出删除/移除工作树的指令时，从
```
git rev-parse --show-toplevel
```
推断目标。

通过比较

git rev-parse --git-dir

和

git rev-parse --git-common-dir

，以及读取

git worktree list --porcelain

，确认它不是主工作树。

从目标路径检查状态，保存目标路径，将执行转移到主/安全工作树，然后运行
```
git worktree remove <target-path>
```
。
仅当用户明确请求强制/丢弃语义，或已确认脏更改可丢弃时，才使用
```
--force
```
。

Phase 4. Move into the new worktree and verify

阶段4. 切换至新工作树并验证

After a create operation:

immediately switch subsequent agent commands to the new worktree path
treat "create and enter/open/switch" as a single operation; do not stop after
```
git worktree add
```
if a persistent shell, tmux pane, or CLI session is available, run
```
cd <path>
```
in that active session and verify with
```
pwd
```
if only tool calls are available, prove the move by running
```
pwd
```
or
```
git status
```
with the tool's
```
workdir=<path>
```
set to the new worktree path
keep every later shell/tool command for this task on
```
workdir=<path>
```
unless there is an explicit reason to operate from another worktree
if an editor, tmux session, or agent was requested, launch it with the new worktree path as its working directory
report
```
cd <path>
```
as the command executed in the persistent session, or as the fallback command the user should run only when the interface cannot mutate the parent shell
do not claim the move happened unless the persistent session changed directories or at least one post-create command actually ran from the new path via
```
workdir=<path>
```
or an equivalent tool working-directory setting

After any operation, report:

worktree path
branch or commit checked out
whether the worktree is clean or dirty
command to enter/open it, and whether the active agent context has been moved there
any setup still needed inside that folder, such as dependency install, environment copy, unique ports, or agent prompt handoff

For removal/cleanup, report what was removed and what remains in

git worktree list

</workflow> <examples>

创建操作完成后：

立即将后续Agent命令切换到新工作树路径
将“创建并进入/打开/切换”视为单个操作；不要在
```
git worktree add
```
后停止
如果有持久化shell、tmux面板或CLI会话可用，在该活动会话中运行
```
cd <path>
```
并使用
```
pwd
```
验证
如果仅支持工具调用，通过设置工具的
```
workdir=<path>
```
为新工作树路径并运行
```
pwd
```
或
```
git status
```
来证明已切换
除非有明确理由从其他工作树操作，否则将此任务的所有后续shell/工具命令保持在
```
workdir=<path>
```
下
如果用户请求编辑器、tmux会话或Agent，以新工作树路径作为工作目录启动它
报告在持久化会话中执行的
```
cd <path>
```
命令，或者当界面无法修改父shell时，报告用户应运行的备用命令
除非持久化会话已更改目录，或至少一个创建后命令通过
```
workdir=<path>
```
或等效工具工作目录设置从新路径运行，否则不要声称已完成切换

任何操作完成后，报告：

工作树路径
检出的分支或提交
工作树是干净还是脏状态
进入/打开它的命令，以及活动Agent上下文是否已转移到那里
该文件夹内仍需进行的设置，例如依赖安装、环境复制、唯一端口或Agent提示移交

对于移除/清理操作，报告已移除的内容以及

git worktree list

中剩余的内容。

</workflow> <examples>

Create a new feature worktree and move into it

创建新特性工作树并切换至其中

If the user only says "create a worktree" and no task is clear, ask first:

text

What work will happen in this worktree?

Then derive the folder name from the answer:

bash

repo_root="$(git rev-parse --show-toplevel)"
branch="feature/auth-session"
folder="auth-session"
path="$repo_root/.hypercore/git-worktree/$folder"
exclude_file="$(git rev-parse --git-path info/exclude)"
mkdir -p "$(dirname "$path")" "$(dirname "$exclude_file")"
grep -qxF ".hypercore/git-worktree/" "$exclude_file" 2>/dev/null || printf '\n.hypercore/git-worktree/\n' >> "$exclude_file"
git fetch --all --prune
git worktree add -b "$branch" "$path" HEAD
git -C "$path" status --short --branch
cd "$path" && pwd

如果用户仅说“创建一个工作树”且未明确任务，先询问：

text

将在这个工作树中进行什么工作？

然后从回答中推导文件夹名称：

bash

repo_root="$(git rev-parse --show-toplevel)"
branch="feature/auth-session"
folder="auth-session"
path="$repo_root/.hypercore/git-worktree/$folder"
exclude_file="$(git rev-parse --git-path info/exclude)"
mkdir -p "$(dirname "$path")" "$(dirname "$exclude_file")"
grep -qxF ".hypercore/git-worktree/" "$exclude_file" 2>/dev/null || printf '\n.hypercore/git-worktree/\n' >> "$exclude_file"
git fetch --all --prune
git worktree add -b "$branch" "$path" HEAD
git -C "$path" status --short --branch
cd "$path" && pwd

List worktrees for review

列出工作树以供评审

bash

git worktree list --porcelain
git worktree list --verbose

bash

git worktree list --porcelain
git worktree list --verbose

Safe cleanup

安全清理

bash

git -C "$path" status --short
git worktree remove "$path"
git worktree prune --dry-run
git worktree prune

bash

git -C "$path" status --short
git worktree remove "$path"
git worktree prune --dry-run
git worktree prune

Delete the current linked worktree from inside it

在工作树内删除当前关联的工作树

When the user is already inside a linked worktree and says "delete this worktree" / "delete worktree", resolve the target before moving out:

bash

target_path="$(git rev-parse --show-toplevel)"
git_dir="$(git rev-parse --git-dir)"
common_dir="$(git rev-parse --git-common-dir)"
main_path="$(git worktree list --porcelain | awk 'NR==1 && /^worktree / {print substr($0, 10)}')"

当用户已在关联工作树内并说出“删除此工作树”/“删除工作树”时，先解析目标再切换出去：

bash

target_path="$(git rev-parse --show-toplevel)"
git_dir="$(git rev-parse --git-dir)"
common_dir="$(git rev-parse --git-common-dir)"
main_path="$(git worktree list --porcelain | awk 'NR==1 && /^worktree / {print substr($0, 10)}')"

Refuse if this is the main worktree or no safe main worktree is available.

如果这是主工作树或没有可用的安全主工作树，则拒绝操作。

if [ "$(cd "$git_dir" && pwd -P)" = "$(cd "$common_dir" && pwd -P)" ] || [ -z "$main_path" ] || [ "$main_path" = "$target_path" ]; then echo "Refusing to remove this path as a linked worktree: $target_path" >&2 exit 1 fi

git -C "$target_path" status --short --branch cd "$main_path" git worktree remove "$target_path" git worktree list --porcelain


</examples>

<validation>

Deterministic regression command:

```bash
python3 skills/git-worktree/scripts/validate-git-worktree-skill.py

Trigger checks:

Positive examples above clearly activate this skill.
Negative examples route away from this skill.
Boundary examples choose Git worktrees only when branch-level isolation is sufficient.

Operation checks:

```
git rev-parse --show-toplevel
```
succeeds before path construction.
create operations have a clear work intent; if missing, one concise question is asked before choosing
```
<folder_name>
```
.
direct
```
git-worktree <ARGUMENT>
```
invocations create from the argument without asking what worktree to create.
clarification questions match the user's language; Korean users are not shown English operation menus.
```
<folder_name>
```
is derived from the stated work intent and sanitized before path construction.
```
.hypercore/git-worktree/
```
is ignored or locally excluded before nested worktree creation.
```
git worktree list --porcelain
```
is read before mutating existing worktrees.
removal checks
```
git -C <path> status --short
```
first unless the user explicitly asks for force removal.
current-worktree deletion resolves the current top-level path first, refuses the main worktree, moves to another safe worktree, and removes the saved target path rather than running removal from inside the target.

cleanup runs

git worktree prune --dry-run

before

git worktree prune

after creation, subsequent commands use the new worktree as their working directory; if the parent shell cannot be persistently changed, the final report includes
```
cd <path>
```
and says whether the active agent context moved there.
the operator did not merely print
```
cd <path>
```
; a persistent session actually changed directory, or at least one post-create command ran from the new worktree via
```
workdir=<path>
```
or an equivalent tool working-directory setting.

Resource placement checks:

Core workflow stays in
```
SKILL.md
```
.
Detailed command policy stays in
```
rules/worktree-lifecycle.md
```
.
External research and pattern rationale stay in
```
references/source-survey.md
```
.

</validation>

if [ "$(cd "$git_dir" && pwd -P)" = "$(cd "$common_dir" && pwd -P)" ] || [ -z "$main_path" ] || [ "$main_path" = "$target_path" ]; then echo "拒绝将此路径作为关联工作树移除：$target_path" >&2 exit 1 fi

git -C "$target_path" status --short --branch cd "$main_path" git worktree remove "$target_path" git worktree list --porcelain


</examples>

<validation>

确定性回归命令：

```bash
python3 skills/git-worktree/scripts/validate-git-worktree-skill.py

触发检查：

上述正向示例明确激活本技能。
上述负向示例不使用本技能。
边界示例仅在分支级隔离足够时选择Git工作树。

操作检查：

```
git rev-parse --show-toplevel
```
在路径构建前执行成功。
创建操作有明确的工作意图；如果缺失，在选择
```
<folder_name>
```
前提出一个简洁的问题。
直接调用
```
git-worktree <ARGUMENT>
```
时，从参数创建工作树，无需询问要创建哪个工作树。
澄清问题匹配用户的语言；韩语用户不会看到英文操作菜单。
```
<folder_name>
```
从指定的工作意图推导并在路径构建前清理。
创建嵌套工作树前，
```
.hypercore/git-worktree/
```
已被忽略或本地排除。
修改现有工作树前读取
```
git worktree list --porcelain
```
。
移除操作先检查
```
git -C <path> status --short
```
，除非用户明确要求强制移除。
当前工作树删除先解析当前顶级路径，拒绝移除主工作树，切换到另一个安全工作树，然后移除保存的目标路径，而非从目标内部运行移除命令。

清理操作先运行

git worktree prune --dry-run

，再运行

git worktree prune

。

创建完成后，后续命令使用新工作树作为工作目录；如果无法持久化修改父shell，最终报告包含
```
cd <path>
```
并说明活动Agent上下文是否已转移到那里。
操作者不仅打印
```
cd <path>
```
；持久化会话实际更改了目录，或至少一个创建后命令通过
```
workdir=<path>
```
或等效工具工作目录设置从新路径运行。

资源放置检查：

核心工作流保留在
```
SKILL.md
```
中。
详细命令策略保留在
```
rules/worktree-lifecycle.md
```
中。
外部研究和模式原理保留在
```
references/source-survey.md
```
中。

</validation>