Use when touching retiring old logic, collapsing duplicate owners, removing fallbacks, or schema/persistence/source-of-truth boundaries; identify opportunities automatically; destructive execution requires explicit confirmation.
中文简介正在准备中。当前显示原文说明。
Use when verified work needs integration or cleanup of an existing task-created branch/worktree, or the user explicitly requests merge, PR, or branch lifecycle handling.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Integration choice and checkout lifetime are separate. Verify first, mutate only task-owned resources, then prove what was removed or retained.
Core principle: fresh evidence -> authorized integration -> ownership-aware cleanup -> Git/path readback.
Announce at start: explain which branch/worktree lifecycle is being closed.
Read the task's TaskStartSnapshot and current repository state. Record:
HEAD, branch/detached state, upstream divergence, and active Git ops;git worktree list --porcelain;Stop on conflicts, unexplained detached state, failed verification, dirty/untracked state in
a cleanup target, or unknown ownership. Do not infer the base from the names
main or master; use task records, repository authority, or explicit user
direction. Never auto-stash, reset, clean, pull, rebase, amend, force-push, or
bypass hooks.
For a trusted host-managed detached checkout, follow the repository's approved managed-workspace contract: verify host binding, default cwd, root, and HEAD; then use its scoped local-commit and native handoff path. Report detached HEAD in the receipt. This exception does not authorize automatic deletion of the detached checkout or bypass unknown ownership/binding.
If no task-created branch/worktree exists and integration was not requested,
skip this workflow: report the local task commit plus Task clean and
Repository clean; do not invent merge/PR ceremony.
Run the smallest current-authority test set that proves the completed task. If it fails, preserve all work and return to diagnosis. Do not present the branch as ready.
When a task branch actually needs disposition, present only applicable choices:
Push, PR, remote deletion, release, and force operations require explicit user authorization. Discard requires a fresh, exact typed confirmation naming branch, worktree path, and commits/delta to lose. Generic agreement is insufficient.
Verify the target checkout is safe, switch to the recorded base, merge without an implicit pull, and rerun verification on the merged result. If integration or verification fails, preserve both histories and stop.
Push only the authorized task branch and create/update the PR with summary and fresh test evidence. PR creation does not itself prove merge and does not require the temporary worktree to remain.
Retain the branch. Remove a clean task-created temporary worktree by default; retain it only for an explicit ongoing-checkout need and report why.
After exact confirmation, remove only the named clean task-owned worktree, then the named branch. If either differs from the confirmation, stop and ask again.
Use evidence matching the merge strategy:
git cherry for rebased commits; stable patch-id or bounded
changed-path/tree comparison for squashes), not an ancestor-only test;Never delete a branch merely because a PR was opened or a similarly named commit exists.
For a clean task-owned resource:
git worktree remove <exact-path>;git worktree list --porcelain;HEAD, and repository status.Do not use routine --force, global git worktree prune, wildcard deletion, or
cleanup of resources absent from the task ownership record. On Windows, Git may
unregister a worktree while its directory remains locked: re-check registration
and the exact resolved path, remove only a proven task-owned clean residual when
safe, otherwise retain it and report the lock/path. Never widen deletion scope.
Report:
Task clean: yes|no and Repository clean: yes|no independently;Task clean means no uncommitted task-owned delta remains. Repository clean
means no staged, unstaged, or untracked repository state remains.
This is a local Git receipt, not authoritative completion or merge truth beyond the evidence read back.
Called only when branch/worktree integration or explicit lifecycle handling is
in scope. Pairs with using-git-worktrees and
verification-before-completion.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Use when touching retiring old logic, collapsing duplicate owners, removing fallbacks, or schema/persistence/source-of-truth boundaries; identify opportunities automatically; destructive execution requires explicit confirmation.
中文简介正在准备中。当前显示原文说明。
Use when defining ambiguous or high-complexity new features, product behavior, UI/component design, architecture choices, contract changes, or when grilling/pressure-testing a plan or design. Routine small requests stay on the fast path.
中文简介正在准备中。当前显示原文说明。
Use when the user asks for caveman mode, fewer tokens, brief responses, compressed communication, or otherwise explicitly requests a much shorter answer.
中文简介正在准备中。当前显示原文说明。
Use when facing 2+ independent tasks without a written plan, with no conflicting shared mutable state or sequential dependencies, where parallel delegation beats inline cost; otherwise inline. Planned tasks use subagent-driven-development.
中文简介正在准备中。当前显示原文说明。
Use when the user asks to establish shared project language, or project work exposes a conflicting, renamed, or deprecated domain term that needs active semantic modeling. Routine small tasks stay on the fast path.
中文简介正在准备中。当前显示原文说明。
Use when executing a written implementation plan across sessions or with review checkpoints. Small or single-slice plans stay inline. For same-session independent tasks, use subagent-driven-development instead.
中文简介正在准备中。当前显示原文说明。