new-worktree

name	new-worktree
description	Creates and initializes a new Git worktree as a sibling directory with automated branching and naming rules based on the latest remote default branch. Use when invoking /new-worktree or requesting a new Git worktree for parallel development, feature work, or bug fixes in external repositories under ~/github. Don't use for the Dart SDK (~/github/dart-sdk), non-Git repositories, or repositories outside ~/github.
key_features	["Git worktree setup off latest origin/main or origin/master","Sibling directory placement","Hard boundary checks for non-Git, outside ~/github, and Dart SDK","Automated branch and folder naming"]

Pre-Flight & Hard Boundaries

Before creating any branch or worktree, verify the current working repository against the following boundaries:

1. Git Exclusivity:
   • Must be a Git repository (git rev-parse --is-inside-work-tree).
   • If not using Git, stop immediately and alert the user.
2. Repository Location (Must be under ~/github):
   • Check the absolute file path of the repository root.
   • Repositories must reside under ~/github (arbitrarily deep, such as ~/github/kevmoo/kevmoo_skills or ~/github/repo).
   • Hard Block: If the repository is located anywhere else, stop and issue a warning asking for explicit human confirmation before proceeding. This prevents mutating internal corporate repositories or bare-repo dotfiles.
3. Dart SDK Exception:
   • Check if the repository maps to the Dart SDK (https://github.com/dart-lang/sdk, e.g., located at ~/github/dart-sdk).
   • Hard Block: If operating in the Dart SDK repository, stop immediately and ask if the user wants to use their specialized Dart SDK flow instead (e.g., dart-sdk-bootstrap). Do not proceed without clarification. The Dart SDK relies on specialized toolchains, gclient checkouts, and dedicated bootstrap workflows that standard Git worktree operations break.

Location & Naming Conventions

When creating a worktree, observe strict placement and naming rules:

• Location: Place the new worktree directory right next to the source repository directory (as a direct sibling in the parent folder).
• Worktree Naming: Format the folder name as _[original repo folder name]-[branch-name].
• Branch Naming: Derive a clean, hyphen-separated branch name from the user request (e.g., issue-12345 or fix-auth-crash).

Examples

• In ~/github/flutter, invoking /new-worktree to fix flutter issue #12345:
  • Creates branch: issue-12345
  • Creates worktree at: ~/github/_flutter-issue-12345
• In ~/github/kevmoo/kevmoo_skills, invoking /new-worktree add lint check:
  • Creates branch: add-lint-check
  • Creates worktree at: ~/github/kevmoo/_kevmoo_skills-add-lint-check

Execution Steps

1. Verify Pre-Flight Boundaries: Confirm location under ~/github, confirm Git repository status, and ensure the repo is not the Dart SDK. Do not require a clean working directory; worktrees allow branching safely from a dirty tree.
2. Fetch Latest Remote State: Run git fetch origin to ensure local tracking branches are up to date. Always base new branches on the latest public default branch (origin/main, origin/master, or origin/HEAD).
3. Formulate Target Names: Determine {branch_name} and sibling directory path {sibling_worktree_path} based on naming rules.
4. Execute Worktree Creation:

   git worktree add -b {branch_name} {sibling_worktree_path} origin/main
   

   (Substitute origin/master or origin/HEAD if appropriate for the repo).
5. Output Clickable Link: Provide the user with a clickable link to the new worktree using the precise scheme [link text](file:///absolute/path/to/worktree). Never wrap link text or syntax in backticks.