Identify normalized repositories and protect their main working tree with an isolated worktree by default; for other repositories, enable worktree only after explicit user selection or when PR creation requests allow it by default. Select reviewable branch/PR topology for dependent changes, determine whether repository changes stay local, are committed, pushed, or submitted as Draft PRs based on a single delivery priority, and follow up on conflicts and CI for existing PRs until they are mergeable or a clear blocker is identified. GitHub native stack is just one execution path and does not take over workstream ownership or domain authorization. Upon completion, judgment evidence, actual topology, baseline, verification results, commit/push status, PR status, and unauthorized actions should be provided.

Before starting writes, use read-only evidence to determine whether the repository already has a formal collaboration or release lifecycle that needs protection. A repository is classified as normalized if any of the following strong evidence holds:

Prioritize reading , , release documentation, manifests, tags, and release workflows, then query remote ruleset, release, and package metadata as needed. A standalone directory name, an uncorroborated / field, the mere presence of a package manifest, or an unexecuted release workflow are not sufficient for classification. When evidence is insufficient, treat the repository as non-normalized and do not upgrade guesses to default worktree permissions.

Once a normalized repository is confirmed, creation or reuse of an owning worktree is allowed by default for regular implementations, fixes, refactors, and operations, without further asking whether to enable it; the main working tree write flow is only used when the user explicitly requests the current checkout. This default only determines the local isolation topology, does not expand the scope of stage/commit/push tasks, and does not authorize force-push, retarget, merge, package/release publishing, or cleanup.

Worktrees created by this skill are uniformly placed under in the current repository root. Prioritize obtaining the repository namespace from the normalized remote URL; use when there is no remote. The target must resolve within the repository's root directory and must not overwrite existing paths.

Platform-hosted worktrees such as those from Codex can also use this root directory, without further subdirectory division by app. Management authority cannot be judged solely by path: first identify the owner by combining current platform capabilities, Git worktree metadata, and task context. Platform-hosted worktrees are responsible for snapshots and automatic cleanup by the platform, and the skill does not manually move, delete, or prune them; worktrees created by native Git have no platform snapshot or automatic cleanup guarantees. When unified Codex paths are needed, point to the current repository's via Codex's Settings > Worktrees > Worktree root.

This directory is local runtime state, not a configuration source of truth. Do not include it in Git, cloud storage, or cross-machine sync; it is created independently on each machine. Git's own is the authoritative state for a single repository, and no separate global registry is created.

First confirm the local version and discover exact syntax along the current command tree:

git --version
git worktree --help
git worktree list --porcelain
git branch --help
git rebase --help
gh pr --help  # 仅当任务需要 GitHub PR 且 gh 可用
gh stack --help  # GitHub stack 请求；用于发现本地扩展是否可用

Only read the help branches needed for the target; do not guess fast-evolving flags from memory or static command tables of external skills. GitHub stack requests follow the native path below by default, and do not require prior proof of support from repository configuration. If the CLI is unavailable, standard Git can still be used to manage branches, and native stacks can be established via GitHub UI/API when server-side capabilities exist. Do not install or upgrade extensions without user request.

Publish authorization only covers stage, commit, push, and PR within the confirmed scope; it does not automatically authorize changing the current branch of the main working tree.

The stable representation of a linear stack is:

main <- data-model <- api <- ui

PR head       PR base
data-model -> main
api        -> data-model
ui         -> api

The user must explicitly request merge/land; "follow to mergeable", fixing CI, or publishing a stack do not authorize merging. After obtaining authorization:

Read official documentation according to the task:

"Check/summarize/explain PR" is a read-only request; for implementation, fix, follow-up, conflict resolution, or making mergeable for existing PRs, local editing, commit, and push to the PR's confirmed head branch are authorized within scope; when the same target and permissions have not changed, commit/push authorization is not requested again due to task resumption or skill loading. It does not authorize force-push, modifying other branches, retarget, or merge.

Cleanup and migration are independent destructive processes. First perform a read-only inventory, then execute a single explicit target:

If the user does require discarding a dirty worktree or unmerged branch, you should re-parse the exact path and ref, clearly explain the unrecoverable content, and obtain confirmation for that target before using force or deleting the branch.

Worktree requests first report normalization judgment evidence and whether the user has opted in; after enablement, report the manager, absolute path, baseline ref, branch/HEAD, setup, and verification. Repository modification reports the delivery endpoint hit by priority, as well as actual local changes, commit, push, and PR; unexecuted subsequent actions must also be clarified. Stack requests report the sole Git outcome owner, owning checkout, worktree enablement status, execution route, trunk, bottom-to-top branch order, and PR base/head for each layer; landing also reports the official stack number, selected scope, final status of each layer, and remaining blockers. PR follow-up reports conflict status, failed checks and judgments, created commits, push target, re-check results, and blockers. Cleanup requests report the exact targets to retain and those that can be safely removed.