A well-organized, highly actionable body whose quickstart and helper scripts are immediately usable. The main deductions are a real `-L` vs `-S` socket-flag inconsistency that makes two sections' commands non-executable as written, plus light redundancy in the monitor-command guidance and the inline helper flag documentation.

Suggestions

Fix the socket flag inconsistency: 'Sending input safely' and 'Watching output' use `tmux -L "$SOCKET"` while everything else uses `tmux -S "$SOCKET"`; `-L` expects a socket name, not a path, so those commands fail as written.

Replace the `tmux ... send-keys` ellipsis abbreviations in the recipes section with complete, copy-paste-ready commands.

Consolidate the twice-stated 'always print a monitor command' guidance into a single rule, and consider trimming the inline wait-for-text.sh flag list since the script documents its own usage.

Dimension	Reasoning	Score
Conciseness	The body is lean and command-first with essentially no explanation of concepts Claude already knows. Minor trimming is possible: the 'always print a copy/paste monitor command' instruction appears twice ("After starting a session ALWAYS tell the user..." and "When giving instructions to a user, explicitly print a copy/paste monitor command"), and the socket path convention is stated in multiple sections. Not a 5 because of that redundancy; clearly not a 3 since there is no padded or over-explained material.	4 / 5
Actionability	The Quickstart block is fully executable copy-paste bash, helper scripts are invoked with concrete flags, and recipes give exact commands (e.g. "tmux ... send-keys -- 'gdb --quiet ./a.out' Enter"). It falls below anchor 5 because of gaps: several recipe lines use the "tmux ..." ellipsis abbreviation rather than complete commands, and 'Sending input safely'/'Watching output' use `tmux -L "$SOCKET"` while every other section uses `tmux -S "$SOCKET"` — `-L` takes a socket name, not a path, so those commands fail as written.	4 / 5
Workflow Clarity	There is a coherent arc — create socket dir, start session, wait for prompt (wait-for-text.sh with timeout and stderr dump on failure), interact, clean up — with explicit validation via pattern polling and exit codes. Minor validation gaps keep it at anchor 4 rather than 5: the Quickstart itself has no verify-session-started checkpoint, and error recovery (e.g. what to do on timeout) is left implicit. The kill-session cleanup is single-target, not a batch/destructive workflow, so the destructive-cap rule is not triggered.	4 / 5
Progressive Disclosure	The body is well sectioned and both referenced bundle files (./scripts/find-sessions.sh, ./scripts/wait-for-text.sh) exist, are one level deep, and are clearly signaled with their invocation documented. Not a 5: the wait-for-text.sh flag list (~15 lines) duplicates the script's own `usage()` output inline, and the skill is over 50 lines, so the simple-skill exception doesn't apply — a references/ split for the per-tool recipes would be the natural next step.	4 / 5
	Total	16 / 20 Passed

Description

66%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 concrete, third-person description with a clear niche and good natural keywords, undermined by the complete absence of a 'when to use' clause. Adding explicit trigger guidance and a few synonym terms would move it into the top band.

Suggestions

Add a 'Use when...' clause, e.g. "Use when driving interactive terminal programs (Python REPL, gdb, psql) or when you need to run and inspect a CLI in a persistent session."

Include additional natural trigger terms users would say: "terminal", "multiplexer", "REPL", "attach", "interactive shell".

Round out the action list for comprehensiveness — e.g. attach for monitoring, poll/wait for output, and session cleanup.

Dimension	Reasoning	Score
Specificity	The description names the domain ("Remote control tmux sessions") and several concrete actions — "sending keystrokes and scraping pane output" — plus concrete tool examples "(python, gdb, etc.)". It falls short of anchor 5 because coverage is not comprehensive (no mention of attaching, polling/waiting for output, or cleanup), but it exceeds anchor 3's '1-2 concrete actions' bar.	4 / 5
Completeness	The 'what' is clearly and concretely stated, but there is no 'Use when...' clause or equivalent explicit trigger guidance anywhere in the description, which the rubric guidelines cap at 3. It is not a 2 because the 'what' is specific, not vague.	3 / 5
Trigger Term Quality	Natural terms include "tmux sessions", "keystrokes", "pane output", "python", "gdb" — words a user needing this skill would plausibly say. A few natural terms are missing ("terminal", "multiplexer", "REPL", "attach"), so it matches anchor 4 rather than anchor 5's synonym-complete coverage.	4 / 5
Distinctiveness Conflict Risk	"tmux sessions" plus "sending keystrokes" / "scraping pane output" carves out a mostly distinct niche with tmux as a distinctive trigger. Minor overlap risk remains with generic 'run python' or 'debugging' skills via "(python, gdb, etc.)", keeping it below anchor 5.	4 / 5
	Total	15 / 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: mitsuhiko/agent-stuff
Path: skills/tmux/SKILL.md
Commit: 0865c84

Reviewed: 8 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.