Isolated Git Workspace
Creates an isolated workspace for feature work, then prepares the project and verifies its clean test baseline.
The skill first detects isolation and requires consent before creating a worktree, and it requires checking that project-local directories are ignored. These controls support scoped operation and reduce repository pollution. Points are deducted because it automatically performs dependency installation, builds, and tests with possible network, filesystem, and environment side effects; sensitive-data handling, complete rollback/cleanup, and command permission boundaries are not specified.
The sequence, submodule guard, native-tool preference, and user confirmation after failures are clear. Points are deducted because tool/dependency detection and test commands are coarse, with limited handling for missing tools, nonstandard or multilingual projects, branch conflicts, and failures beyond worktree creation; static review cannot prove execution, so the score stays at or below 10.
The trigger is clear: feature work requiring isolation or execution of an implementation plan. It also describes branches for existing worktrees, submodules, user refusal, and native tools. Points are deducted for limited handling of non-Git directories, complex repository layouts, Chinese-language prompts, and platform-specific commands, with incomplete non-fit boundaries.
The document has clear layers with overview, steps, quick reference, common mistakes, and red flags; repository context supplies an MIT license, version, and maintenance/community signals. Points are deducted because the skill lacks its own changelog, explicit maintenance owner, update path, parameter contract, and FAQ, while installation and dependency guidance relies on repository-level context.
For a typical Git project, isolation detection, worktree creation, setup, and baseline testing address the core goal with directly usable reporting. Points are deducted because automatic installation and test selection may require manual adjustment, native-tool availability cannot be verified statically, and there is no skill-specific representative output or comparative evidence; the static cap is 7.
Commands, decision tables, and report templates provide auditable static evidence, and the repository includes general test material. Points are deducted because the supplied tests do not cover this skill's key paths, and there is no independent reproduction record or third-party execution evidence; the static cap is 5.
- npm install, pip install, poetry install, and go mod download may create network and supply-chain risk; run them only after confirmation in a controlled environment.
- The skill instructs adding to .gitignore and committing when a directory is not ignored, but provides no additional pre-commit confirmation or rollback guidance.
- The baseline test commands are generalized examples and may not fit nonstandard projects, leaving some diagnosis to the user.
- The publisher is not verified by the FollowSkills enterprise registry and is treated as unknown.
What does this skill do, and when should you use it?
This skill ensures that feature work starts in an isolated environment. It first detects whether the current directory is already a linked Git worktree or a submodule, then prefers the platform’s native workspace tools. If no native tool is available, it falls back to a manual Git worktree, performs supported project setup, and runs baseline tests. It fits development workflows that need branch isolation and evidence about the project’s starting state.
Reads Git’s worktree directory, common Git directory, current branch, and superproject path to detect existing isolation; asks for consent before creating a worktree in a normal checkout; prefers available native worktree tools, otherwise verifies that a project-local worktree directory is ignored and runs git worktree add with a new branch; conditionally runs setup commands based on package.json, Cargo.toml, requirements.txt, pyproject.toml, or go.mod; runs npm test, cargo test, pytest, or go test ./... as appropriate; and reports workspace and baseline test status.
- A developer starting feature work without wanting to alter the current branch.
- A team executing an implementation plan that requires each task to begin from an isolated branch.
- A maintainer who wants existing tests checked before implementation begins.
- A user of a coding agent with native workspace support who wants that mechanism preferred automatically.
What are this skill's strengths and limitations?
- Detects existing worktrees and submodules before creating anything.
- Prefers native workspace tools and provides a Git worktree fallback.
- Verifies that a project-local worktree directory is ignored.
- Runs project setup and baseline tests before implementation proceeds.
- Creating a worktree in an ordinary checkout requires user consent.
- Baseline test failures pause the workflow and require a decision, adding startup time.
- Setup detection is explicitly described only for Node.js, Rust, Python, and Go projects.
- The source provides no standalone package or independent behavior-test results for this skill.
How do you install this skill?
This skill has no documented standalone installation command. It is part of the obra/superpowers collection at skills/using-git-worktrees/SKILL.md; install the full Superpowers collection through the supported method for your coding harness. The README states that installation is separate for each harness.
How do you use this skill?
Start a task with an installed Superpowers-enabled coding agent and request isolation, for example: “Create an isolated workspace for this feature, then execute the implementation plan.” The skill checks the current isolation state first and asks for consent when the checkout is ordinary and no preference was declared. The source does not define a dedicated trigger syntax.
How does this skill compare with similar options?
When native workspace tools are available, the skill prefers them; otherwise it uses a manual Git worktree as the fallback.