CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

git-worktree-status

Check status of background verification tasks running in a git worktree

Quality

70%

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 ./examples/skills/git-worktree-status/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

75%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, action-oriented skill body with concrete executable checks and clear report formats. Its main weaknesses are a correctness bug in the build-status check, a grep that lists all tests rather than failed ones, and some redundant sections.

Suggestions

Fix the build-status check: `if [ $? -eq 0 ]` evaluates the `[ -f "$LOG" ]` test, not the build result, so build status always reports PASS when a log exists — capture the build exit code in the log or echo a status line into it.

In the test-failure branch, filter to failed tests (e.g. parse entries where numFailedTests-related fields or failed statuses appear) instead of `grep '"fullName"'`, which lists every test.

Trim the redundant Quick reference table and Usage section, and verify the `../../commands/*.md` suite links resolve from the skill's installed location.

DimensionReasoningScore

Conciseness

The body is lean and code-first with no explanations of concepts Claude already knows, but the Quick reference table and the Usage section largely duplicate the detailed check sections and report format, fitting the anchor for efficient content with minor instances that could be trimmed.

4 / 5

Actionability

Mostly executable, copy-paste-ready bash for detection, log parsing, and re-running checks, but the build-status branch tests `[ $? -eq 0 ]` on the preceding `[ -f "$LOG" ]` result rather than the build outcome, and the test-failure branch greps all '"fullName"' entries instead of only failed tests — concrete code with notable gaps rather than fully correct.

4 / 5

Workflow Clarity

The detect → read logs → parse → report sequence is clear and each step has executable code, a worktree guard, and failure branches with actionable next steps, but there are minor validation gaps such as no handling of stale or partially written logs from still-running tasks.

4 / 5

Progressive Disclosure

Content is well-organized into clearly signaled sections with nothing inlined that belongs in a separate file, but the suite cross-links ([../../commands/git-worktree.md] etc.) point outside the bundle and do not resolve, leaving minor navigation gaps.

4 / 5

Total

16

/

20

Passed

Description

53%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 identifies a specific, distinctive niche but is under-specified: it names only one action, omits the concrete check types it reports on, and lacks any "Use when" trigger guidance. Adding an explicit trigger clause and enumerating the checks (type check, tests, build) would lift it substantially.

Suggestions

Add a 'Use when...' trigger clause to the description, e.g. 'Use when asked about worktree status, background test/build results, or whether verification tasks finished.'

Enumerate the specific checks to improve specificity and trigger coverage: 'Check status of background verification tasks (type check, tests, build) running in a git worktree.'

Include natural synonyms users would say, such as 'worktree status', 'test results', and 'build results'.

DimensionReasoningScore

Specificity

The description names a precise domain ("background verification tasks running in a git worktree") with one concrete action ("Check status"), matching the anchor for domain plus 1-2 concrete actions without comprehensive coverage; it does not list the specific checks (type check, tests, build), which keeps it below 4, while its domain specificity keeps it above the generic-action level 2.

3 / 5

Completeness

The description gives a clear "what" ("Check status of background verification tasks") but contains no "Use when..." clause or equivalent trigger guidance, which per the judging guidelines caps completeness at 3; the separate when_to_use frontmatter field restates the what rather than providing trigger conditions.

3 / 5

Trigger Term Quality

Terms like "status", "worktree", and "verification" are natural user language, but common phrasings users would actually say ("tests", "build", "type check", "is the build done") are missing, fitting the anchor for some relevant keywords missing common variations.

3 / 5

Distinctiveness Conflict Risk

The niche is mostly distinct — checking background verification task status in a worktree differs from the sibling create/remove/clean commands — with only minor overlap risk against generic git status queries, matching the anchor for mostly distinct with minor overlap.

4 / 5

Total

13

/

20

Passed

Validation

87%

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

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

relative_links

Relative link issues: 4 suspicious

Warning

Total

14

/

16

Passed

Repository

FlorianBruniaux/claude-code-ultimate-guide

Path

examples/skills/git-worktree-status/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.