x-worktree-isolate

Use when the user runs multiple git worktrees of the same repo in parallel and hits docker-compose container_name / port / volume collisions OR has stateful singletons (Slack/Discord bots, schedulers, webhook receivers, host crontabs) that must not run concurrently across worktrees. Singleton-aware in v0.2. Wraps inspector + override emitter + worktrunk hook.

2.63x

Quality

80%

Does it follow best practices?

Impact

100%

2.63x

Average score across 1 eval scenario

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/x-worktree-isolate/SKILL.md

Quality

Content

81%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 highly actionable, well-sequenced skill body with strong validation checkpoints and a clean reference structure; its main weakness is conciseness — version-migration history and several schemas/contracts are inlined rather than pushed to references or a deprecated section.

Suggestions

Move the v0.2/v0.3 migration blockquotes and inline version numbers (0.3.1, schema 1→2) into a dedicated 'Migration / old patterns' section or a references file, keeping only the current-schema behavior in the main flow.

Relocate the state.local.json and feature-overrides.local.json schema tables plus the detailed x-worktree integration contract into references/ (e.g. references/state-schema.md, references/x-worktree-integration.md), leaving a one-line pointer in SKILL.md.

De-duplicate the singleton enforcement semantics, which are described in both the 'Singletons (v0.3)' prose and the 'Enforcement (v0.3)' paragraph.

Dimension	Reasoning	Score
Conciseness	Mostly efficient and dense with useful specifics, but version-migration history (v0.2 hard-reject, v0.3 self-heal blockquotes) and inline version numbers (0.3.1, schema 1→2) are time-sensitive detail placed inline rather than in a deprecated/old-patterns section, and the enforcement semantics are partly restated across sections.	3 / 5
Actionability	Fully executable guidance throughout — exact subcommands and flags ('init --rescan', 'apply --quiet --if-profile-exists', 'enable <id> --force'), concrete file paths, JSON schemas, exit codes, and copy-paste-ready launch commands covering the common cases.	5 / 5
Workflow Clarity	Clear two-phase INSPECT/APPLY model, a 17-step sequenced subcommand list, a signal→subcommand detection table, and explicit validation checkpoints (doctor asserts overridden ports are exposed, apply hard-blocks on severity:blocker, ack-host-singletons gate) with feedback loops for error recovery.	5 / 5
Progressive Disclosure	Well-organized sections with one-level-deep, clearly signaled references (all six references/*.md and the named scripts exist); however sizable content that could live in references — state.local.json schema, feature-overrides schema, and the full x-worktree integration contract — is inlined in SKILL.md.	4 / 5
	Total	17 / 20 Passed

Description

78%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 strong, highly specific description with an explicit 'Use when' trigger and a distinct niche; its main weakness is a jargon-heavy 'what' clause ('Wraps inspector + override emitter + worktrunk hook') that is less clear to a user than the rest.

Suggestions

Rewrite the 'what' clause in user-facing terms, e.g. 'Generates per-worktree compose overrides and .env files that remap container names, ports, and data dirs, and serializes stateful singletons', replacing the 'Wraps inspector + override emitter + worktrunk hook' implementation jargon.

Add one or two natural trigger phrases currently only in the body ('compose project name collision', 'port conflict between worktrees') to broaden keyword coverage in the description itself.

Dimension	Reasoning	Score
Specificity	Names the domain (docker-compose worktree isolation) and several concrete capabilities — resolving container_name/port/volume collisions and handling stateful singletons across worktrees — but the 'what' clause ('Wraps inspector + override emitter + worktrunk hook') is implementation jargon rather than user-facing actions, leaving a minor coverage gap.	4 / 5
Completeness	Has an explicit 'Use when...' clause with concrete collision/singleton triggers and a 'what' statement, satisfying both halves; the 'what' is terse and mechanism-focused, so it is not the maximally explicit anchor-5 form.	4 / 5
Trigger Term Quality	Strong natural keywords users would say ('parallel', 'git worktrees', 'container_name / port / volume collisions', 'Slack/Discord bots', 'host crontabs') with good synonym coverage; a few common phrasings like 'compose project name collision' appear only in the body, not the description.	4 / 5
Distinctiveness Conflict Risk	Targets a clear niche — parallel git worktrees of one repo hitting docker-compose collisions or concurrent singletons — with triggers unlikely to fire for unrelated skills.	5 / 5
	Total	17 / 20 Passed

Validation

100%

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

Validation for skill structure

No warnings or errors.

Repository: quangtran88/x-skills
Path: skills/x-worktree-isolate/SKILL.md
Commit: f17a69e

Reviewed: 6 days 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.