using-git-worktrees
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
62
72%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/using-git-worktrees/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has a clear 'Use when' clause that addresses both what and when, which is its strongest aspect. However, it lacks specificity in concrete actions (what exactly does it do beyond 'ensures an isolated workspace exists'?) and could benefit from more natural trigger terms that users would actually say. The phrase 'native tools' is vague and the overall description reads more like an internal implementation note than a user-facing skill selector.
Suggestions
Add more concrete actions describing what the skill does, e.g., 'Creates git worktrees, sets up isolated branches, or provisions separate working directories for parallel feature development'
Include more natural trigger terms users would say, such as 'branch', 'new feature branch', 'parallel development', 'separate workspace', 'worktree setup'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It mentions some actions ('starting feature work', 'ensures an isolated workspace exists', 'git worktree fallback', 'native tools') but doesn't list multiple concrete specific actions. The description is more about the purpose than the specific operations performed. | 2 / 3 |
Completeness | The description explicitly answers both 'what' (ensures an isolated workspace exists via native tools or git worktree fallback) and 'when' ('Use when starting feature work that needs isolation from current workspace or before executing implementation plans'). | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'feature work', 'isolated workspace', 'git worktree', and 'implementation plans', but misses common user phrases like 'branch', 'new feature', 'separate environment', 'worktree', or 'sandbox'. The phrase 'native tools' is vague and not a natural user term. | 2 / 3 |
Distinctiveness Conflict Risk | The concept of 'isolated workspace' and 'feature work' is somewhat specific, but 'implementation plans' and 'starting feature work' are broad enough to potentially overlap with other development workflow skills like branching, project setup, or CI/CD skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-crafted, highly actionable skill with a clear multi-step workflow, proper validation checkpoints, and good error recovery paths. Its main weakness is moderate redundancy — the Quick Reference, Common Mistakes, and Red Flags sections substantially overlap with each other and the main workflow, adding ~60 lines that could be consolidated. The decision tree logic (detect → native tool → git fallback) is well-structured and the submodule guard is a thoughtful edge case handler.
Suggestions
Consolidate the Quick Reference table, Common Mistakes, and Red Flags sections into a single compact reference — they repeat the same guidance in three different formats.
Consider removing the 'Announce at start' instruction as it adds little value and consumes tokens on every invocation.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some redundancy — the Quick Reference table, Common Mistakes, and Red Flags sections overlap significantly with each other and with the main workflow steps. The "Always/Never" lists largely restate what the steps already cover. Some tightening is possible, though most content is genuinely useful. | 2 / 3 |
Actionability | The skill provides concrete, executable bash commands throughout — detection checks, directory selection, worktree creation, project setup, and test verification are all copy-paste ready. Decision logic is explicit with clear conditionals and fallback paths. | 3 / 3 |
Workflow Clarity | The multi-step workflow is clearly sequenced (Step 0 → 1a → 1b → 3 → 4) with explicit validation checkpoints: submodule guard in Step 0, git check-ignore verification before creation, sandbox fallback on permission errors, and baseline test verification with a feedback loop (report failures, ask whether to proceed). | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and a useful quick reference table, but it's a long monolithic file (~180 lines) with no references to external files. The Common Mistakes and Red Flags sections could be split out or consolidated to reduce the main file's length, though for a standalone skill without bundle files this is acceptable. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- obra/superpowers
- Commit
f2cbfbe
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.