create-worktree

Create or reuse a git worktree for a pull request or branch so reviews and work happen in isolation

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

96%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.

The body is a tightly written, fully executable workflow with concrete commands, explicit validation checkpoints, and an error-recovery feedback loop. The only minor gap is organization polish in an otherwise self-contained single-file skill.

Dimension	Reasoning	Score
Conciseness	The body is lean: it jumps straight into parsing arguments and concrete steps with no preamble explaining what a git worktree is or how git/libraries work. The single explanatory line ("gh pr checkout handles fetching, fork tracking, and branch setup automatically") and the worked path example both earn their place by preventing redundant manual steps, so every token pulls its weight. This is not the verbose 4-anchor case; it sits cleanly at the lean, competence-assuming 5 anchor.	5 / 5
Actionability	Commands are concrete and copy-paste ready throughout — `mkdir -p`, `git worktree list`, `gh pr view --json headRefName -q .headRefName`, `git worktree add ... [--detach]`, `gh pr checkout`, `cd`, `pwd`, `git checkout --no-track -b`. Branching logic covers the common cases (PR, branch, neither) and includes a concrete AskUserQuestion interaction.	5 / 5
Workflow Clarity	Steps are explicitly numbered 1-4 with a clear sequence, and validation is present: step 3 verifies cwd via `pwd` and stops with an error if it didn't persist, and step 2 detects branch conflicts via `git worktree list` and runs an AskUserQuestion feedback loop (reuse vs. stop). This matches the anchor with explicit validation steps and error-recovery feedback loops; the destructive/batch cap does not apply because validation is included.	5 / 5
Progressive Disclosure	No bundle files exist (references/, scripts/, assets/ are all absent), and the skill is a self-contained single file organized into a clear Steps section with numbered subsections. Structure is good and content is appropriately placed for a single-purpose skill, but it sits slightly above the under-50-line simple-skill threshold and has minor organization looseness (e.g. the explanatory `gh pr checkout` bullet under step 2), placing it at 4 rather than 5.	4 / 5
	Total	19 / 20 Passed

Description

65%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.

The description states a clear, distinctive purpose with concrete actions and natural trigger terms, but lacks an explicit "Use when..." clause, which caps its completeness. Adding a trigger clause would move it toward a 4-5 overall.

Suggestions

Add an explicit "Use when..." trigger clause, e.g. "Use when setting up an isolated checkout to review or work on a PR or branch."

Expand the action list slightly (e.g. mention checkout/switch) to raise specificity toward 4-5.

Include a common synonym such as "PR checkout" or "isolated checkout" to round out trigger-term coverage.

Dimension	Reasoning	Score
Specificity	"Create or reuse a git worktree for a pull request or branch" names the domain and two concrete actions (create, reuse) but is not comprehensive — it omits the checkout/switch mechanics detailed in the body. This matches the anchor that names a domain with 1-2 concrete actions, and falls short of 4 which requires several specific actions.	3 / 5
Completeness	The "what" is clear (create or reuse a git worktree), but the "when" is only implied by the purpose clause "for a pull request or branch so reviews and work happen in isolation" — there is no explicit "Use when..." trigger, which per the judging guidelines caps completeness at 3.	3 / 5
Trigger Term Quality	Includes natural terms a developer would say — "git worktree", "pull request", "branch", "reviews", "work", "isolation" — with good coverage; a few natural synonyms (e.g. "PR checkout", "isolated checkout") are missing, so it is above the midpoint rather than comprehensive.	4 / 5
Distinctiveness Conflict Risk	The phrase carves out a clear niche (git worktrees for PR/branch review in isolation) with distinct triggers and minimal overlap risk with other skills.	5 / 5
	Total	15 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: dlt-hub/dlt
Path: .claude/skills/create-worktree/SKILL.md
Commit: 04c80cd

Reviewed: about 16 hours ago

Table of Contents

Discovery Implementation Validation

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.