CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./src-tauri/experts/skills/using-git-worktrees/SKILL.md

The canonical home for this skill is using-git-worktrees in obra/superpowers

SKILL.md
Quality
Evals
Security

Quality

Content

67%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable procedural skill with explicit validation checkpoints, error-recovery paths, and a decision table covering the main situations. Its main weaknesses are significant cross-section redundancy (the native-tool-first rule is stated four times), a creation snippet with undefined variables, and a missing Step 2 in the workflow numbering.

Suggestions

Consolidate the overlapping "Quick Reference", "Common Mistakes", and "Red Flags" sections — they restate the same three rules (native tools first, verify ignore, run detection) multiple times; one checklist plus one mistakes section would cut ~40 lines.

Make the worktree creation snippet fully executable by defining BRANCH_NAME (e.g., a suggested naming convention) and providing concrete path assignments instead of comment-only placeholders for "$path".

Fix the step numbering (there is no Step 2; the flow jumps from Step 1 to Step 3) so the sequence reads coherently.

DimensionReasoningScore

Conciseness

The body is mostly efficient with concrete commands and no explanations of concepts Claude already knows, but the same guidance is repeated three to four times across "Step 1a" ("Using `git worktree add` when you have a native tool creates phantom state"), "Common Mistakes" ("Fighting the harness"), "Red Flags" ("Use `git worktree add` when you have a native worktree tool... This is the #1 mistake"), and the Quick Reference table. This matches "Mostly efficient but includes some unnecessary explanation or could be tightened"; it is above anchor 2 because there is no concept padding, and below anchor 4 because the redundant sections are a clear trim target.

3 / 5

Actionability

Mostly executable guidance: detection (git rev-parse / --show-superproject-working-tree), directory selection (ls -d, git check-ignore), setup, and test commands are all concrete and runnable. It falls short of anchor 5 because the creation block is not copy-paste ready — "$BRANCH_NAME" is never defined and "$path" exists only as comments ("# For project-local: path=\"$LOCATION/$BRANCH_NAME\"") — and "npm test / cargo test / pytest / go test" is a choose-one placeholder, matching "concrete code or commands with minor gaps".

4 / 5

Workflow Clarity

The sequence is clear with strong checkpoints: Step 0 isolation detection with a submodule guard, mandatory git check-ignore verification before creation, sandbox-permission fallback, and baseline test verification with an explicit failure protocol ("If tests fail: Report failures, ask whether to proceed"), plus a Quick Reference checklist. It misses anchor 5 because the step numbering is incoherent — there is no Step 2 (the flow jumps from Step 1 to "Step 3: Project Setup"), leaving a visible gap in the sequence — a minor clarity flaw consistent with anchor 4's "minor validation gaps".

4 / 5

Progressive Disclosure

No bundle files exist, and the single-file body is well structured with clear section headers (Overview, Steps, Quick Reference, Common Mistakes, Red Flags) and easy navigation via the situation/action table; no content is buried or nested. It fits "Good structure; most content is appropriately placed; minor organization gaps" — below anchor 5 because at ~215 lines with heavy Quick Reference/Common Mistakes/Red Flags overlap, the content is not split or tightened the way a well-disciplined overview would be, though nothing here clearly demands a separate reference file.

4 / 5

Total

15

/

20

Passed

Description

70%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A solid description with an explicit "Use when" clause, a clear statement of what it does, and the key term "worktree" present. Its main weaknesses are that it names only one abstract action ("ensures an isolated workspace exists") and its trigger phrases describe internal states rather than words a user would naturally say.

Suggestions

List the concrete actions the skill performs (e.g., "Detects existing worktree isolation, creates isolated worktrees via native tools or git worktree fallback, verifies gitignore coverage, and runs baseline tests") to raise specificity.

Add natural user-facing trigger phrasing such as "Use when the user asks for a worktree, an isolated workspace, or a separate checkout for feature work" to make the 'when' clause more concrete.

Narrow the "before executing implementation plans" trigger (e.g., "before executing implementation plans that modify the working tree") to reduce overlap with plan-execution skills.

DimensionReasoningScore

Specificity

The description names the domain and mechanism ("ensures an isolated workspace exists via native tools or git worktree fallback") but describes a single ensure-action with two mechanisms rather than listing several concrete actions, matching "Names domain and 1-2 concrete actions, but not comprehensive". It is below anchor 4 because it does not enumerate multiple specific operations (detect, create, verify ignore, run baseline tests), and above anchor 2 because the mechanisms are concrete rather than generic.

3 / 5

Completeness

Both parts are explicit: the what ("ensures an isolated workspace exists via native tools or git worktree fallback") and an explicit when ("Use when starting feature work that needs isolation from current workspace or before executing implementation plans"). It falls short of anchor 5 because the trigger phrases are somewhat abstract state descriptions rather than concrete phrases a user would utter (e.g., "when the user asks for a worktree or isolated workspace"), matching "'when' could be more explicit or specific".

4 / 5

Trigger Term Quality

Includes good natural keywords — "feature work", "isolation", "workspace", "implementation plans", and "worktree" (via "git worktree fallback") — that a user needing this skill would plausibly say. A few natural variations are missing (e.g., "isolated workspace" as a phrase, "parallel branch", "separate checkout"), so it fits "Good keyword coverage; a few natural terms missing" rather than the comprehensive synonym coverage of anchor 5.

4 / 5

Distinctiveness Conflict Risk

The worktree/isolation niche is mostly distinct with clear triggers, but "before executing implementation plans" is broad and could overlap with plan-execution or branching skills, fitting "Mostly distinct; minor overlap risk with closely related skills". It is above anchor 3 because the core isolation focus is unmistakable, and below anchor 5 because of that plan-execution overlap.

4 / 5

Total

15

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

arwei944/codeg

Path

src-tauri/experts/skills/using-git-worktrees/SKILL.md

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.