CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/cli-output-conventions

Conventions for designing AND testing CLI output so it stays parseable and assertable - exit-code policy (0 success, non-zero failure with stable codes per failure mode), `stdout` for primary data / `stderr` for messages, `--json` / `--plain` for machine-readable output, deterministic ordering and timestamps, `NO_COLOR` / TTY-aware color, `-q` / `--verbose` discipline, and stable `--help` / `--version`. Built on the [Command Line Interface Guidelines][clig]. Use when designing or testing a CLI's output - a new flag, command, or error message, writing CLI assertions, or fixing flaky tests caused by non-deterministic output; it is the assertion contract for `bats-testing` and tells `tui-snapshot-tester` what does NOT need a snapshot.

72

Quality

91%

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

Overview
Quality
Evals
Security
Files

Quality

Content

78%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 delivers a tight, well-structured conventions contract: every inline convention pairs a policy decision with an executable bats test pattern, the anti-patterns table maps failures to fixes, and conventions 5-8 are appropriately deferred to a real one-level-deep reference file. Minor deductions for verbatim clig quotes restating widely-known rules and for Convention 4's golden-file test pattern being named but not shown.

Suggestions

Compress the clig block quotes that restate well-known rules (stdout vs stderr separation, zero-on-success) into one-line citations, keeping only quotes that define specific policy not already known.

Add an actual bats golden-file test snippet under Convention 4 (determinism) so all four in-body conventions have copy-paste-ready test patterns.

DimensionReasoningScore

Conciseness

Mostly efficient: no section explains basic concepts at length, and the bulk is project-specific value (the exit-code mapping table, "JSON is the contract", determinism rules, the Bats 1.5+ `run --separate-stderr` detail). However, verbatim clig quotes like "Send output to `stdout`... Send messaging to `stderr`" and "Return zero exit code on success, non-zero on failure" restate rules Claude already knows. Not 5 because those redundant quotations could be trimmed to one-line citations; not 3 because no section is padded and every convention carries concrete non-obvious decisions.

4 / 5

Actionability

Mostly executable, copy-paste-ready guidance: `run mycli --nonexistent; [ "$status" -eq 2 ]`, `run --separate-stderr mycli list`, and `echo "$output" | jq -e '.[0] | has("name") and has("status")'` are real, runnable bats assertions. Not 5 because Convention 4's "Test pattern: golden-file comparison with sorted output" names the technique without showing a snippet, leaving one of the four in-body conventions without executable code; not 3 because the shown code is complete, correct, and covers the common cases.

4 / 5

Workflow Clarity

Each convention follows a clear repeated structure — rule, good/bad example, then test pattern — and the test patterns act as explicit checkpoints (assert the specific code, assert stream separation, assert the JSON schema). "Fix the output, not the assertion" gives unambiguous remediation direction, and the anti-patterns table maps each failure to a fix and convention. Not 5 because Convention 4's verification approach is named but not specified (no golden-file example); not 3 because the checkpoints for conventions 1-3 are explicit and the diagnostic path for flaky tests is clear.

4 / 5

Progressive Disclosure

Clean split, verified against the actual bundle: conventions 1-4 with test patterns stay inline (~200 lines), and "The remaining four conventions and their bats test patterns are in [references/conventions-5-8.md](references/conventions-5-8.md)" points to a real, one-level-deep file (75 lines) that contains its own organized sections and bats code. References section lists external resources without nesting. Not 4 because navigation is explicit, the split point is sensible, and there are no organization gaps or buried references.

5 / 5

Total

17

/

20

Passed

Description

100%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 is exceptionally strong: it enumerates seven concrete CLI output conventions (what) and pairs them with an explicit 'Use when...' clause covering design, testing, and flaky-test remediation scenarios (when). It goes further than most by explicitly disambiguating its role against the two sister skills (bats-testing, tui-snapshot-tester), minimizing trigger conflicts.

DimensionReasoningScore

Specificity

Enumerates multiple concrete capabilities with comprehensive coverage: "exit-code policy (0 success, non-zero failure with stable codes per failure mode)", "`stdout` for primary data / `stderr` for messages", "`--json` / `--plain` for machine-readable output", "deterministic ordering and timestamps", "`NO_COLOR` / TTY-aware color", "`-q` / `--verbose` discipline, and stable `--help` / `--version`" — every major CLI output surface is named, none vaguely. Not 4 because there are no coverage gaps; each named convention is a concrete, checkable behavior rather than a generic action.

5 / 5

Completeness

Both what and when are explicit and concrete: what is "Conventions for designing AND testing CLI output so it stays parseable and assertable" with the full convention enumeration, and when is "Use when designing or testing a CLI's output - a new flag, command, or error message, writing CLI assertions, or fixing flaky tests caused by non-deterministic output". Not 4 because the when-clause is fully explicit with concrete trigger phrases, not merely present or loosely worded.

5 / 5

Trigger Term Quality

Natural user phrasings appear on both the design and testing sides: "a new flag, command, or error message", "writing CLI assertions", "fixing flaky tests caused by non-deterministic output" — exactly what a user would say when they need this skill. Not 4 because it covers the natural synonyms across scenarios (designing output, writing tests, flaky/brittle tests, non-deterministic output, parseable/assertable) rather than leaving common variations out.

5 / 5

Distinctiveness Conflict Risk

Clear niche (CLI output contract) with active disambiguation from the closest overlapping skills: "it is the assertion contract for `bats-testing` and tells `tui-snapshot-tester` what does NOT need a snapshot". Not 4 because overlap risk is not just low but explicitly addressed by stating what this skill is and is not relative to its sister skills.

5 / 5

Total

20

/

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.

Reviewed

On this page