flow-next-worktree-kit
Scannednpx machina-cli add skill gmickel/gmickel-claude-marketplace/flow-next-worktree-kit --openclawWorktree kit
Use the manager script for all worktree actions.
bash ${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/flow-next-worktree-kit/scripts/worktree.sh <command> [args]
Commands:
create <name> [base]listswitch <name>(prints path)cleanupcopy-env <name>
Safety notes:
createdoes not change the current branchcleanupdoes not force-remove worktrees and does not delete branchescleanupdeletes the worktree directory (including ignored files); removal fails if the worktree is not clean.env*is copied with no overwrite (symlinks skipped)- refuses to operate if
.worktrees/or any worktree path component is a symlink copy-envonly targets registered worktreesoriginfetch is optional; local base refs are allowed- fetch from
originonly when base looks like a branch - Worktrees live under
.worktrees/
Source
git clone https://github.com/gmickel/gmickel-claude-marketplace/blob/main/plugins/flow-next/skills/flow-next-worktree-kit/SKILL.mdView on GitHub Overview
Flow-next-worktree-kit helps you manage multiple git worktrees for parallel feature work, isolated reviews, and a clean workspace. It wraps a manager script to create, list, switch, cleanup worktrees and copy environment files (.env) safely, with safeguards around symlinks and worktree directories.
How This Skill Works
Use the included worktree.sh script with commands: create, list, switch, cleanup, copy-env. Worktrees live under .worktrees/; create does not change the current branch, and cleanup removes the worktree directory only if it’s clean. When copying env files, .env* is copied without overwriting and symlinks are skipped; operations are restricted to registered worktrees to prevent unintended changes.
When to Use It
- Develop multiple features in parallel without polluting the main repo history.
- Conduct isolated code reviews in dedicated worktrees tied to specific branches or PRs.
- Start a new task with a clean workspace, avoiding residual changes from other worktrees.
- Test across different base branches or environments by creating separate worktrees from different bases.
- When asked to set up or manage worktrees manually or copy environment configs to a specific worktree.
Quick Start
- Step 1: Create a worktree for a new feature: bash ${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/flow-next-worktree-kit/scripts/worktree.sh create feature-x base/main
- Step 2: Switch to the new worktree: bash ${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/flow-next-worktree-kit/scripts/worktree.sh switch feature-x
- Step 3: Propagate envs to the worktree: bash ${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/flow-next-worktree-kit/scripts/worktree.sh copy-env feature-x
Best Practices
- Create worktrees with an explicit base and avoid switching the current branch during creation.
- Before cleanup, ensure the worktree is clean (no in-progress changes) to prevent data loss.
- List existing worktrees before creating, switching, or deleting to know what’s active.
- Use copy-env only on registered worktrees and expect no overwrites of existing .env files.
- Validate safety: ensure .worktrees/ and all path components are not symlinks before operations.
Example Use Cases
- Create a feature-x worktree from main to work on a new PR without touching the main repo state.
- List all current worktrees to plan a review session for feature-y.
- Switch to the feature-x worktree to perform quick local testing or code checks.
- After a feature is merged, cleanup the associated worktree to reclaim space.
- Copy environment variables into a feature worktree to mirror local config for testing.