CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

qa-cli

QA tests for the Zipper CLI. Exercises Standard, Loadfile-Only, Chaos Engine, Production Set, Source-Driven Generation, Load File Formats, Archive Test Fixtures, Production Manifest comparison, version output, and CLI boundaries.

Quality

78%

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 ./.factory/skills/qa-cli/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.

The body is a well-structured, highly executable QA playbook: exact build and CLI commands, explicit per-flow verification criteria, and a failure-modes checklist that anticipates real pitfalls. All dimensions land at 4 due to consistent minor gaps — undefined shell variables in the interaction section, no explicit recovery step when a Verify fails, and a flow menu that could be split into a reference file. It is a strong skill with no serious structural defects.

Suggestions

Trim the driver-mechanics detail in the interaction section (snapshot placement, command-position rules) now delegated to droid-control, keeping only the Zipper-specific requirements such as the env -u CI prefix and APP_EXIT:$? marker.

Add one line of error-recovery guidance for failed positive flows, e.g. "If a Verify step fails on a positive flow, re-run once, record the observed output in Notes, and report the flow as failing rather than omitting it."

Move the 12-flow menu details into a references/flows.md file (keeping a one-line-per-flow menu in SKILL.md) so the orchestrator's overview stays lean as flows are added.

Define $TCTL and $session, or replace them with the literal tctl invocation, so the interaction snippet is copy-paste executable.

DimensionReasoningScore

Conciseness

The body is dense and imperative with no explanations of concepts Claude already knows — every flow is a command plus expected outcomes. It is anchor 4 rather than 5 because the interaction section states "Droid Control owns driver mechanics, Capture, and Verify" yet then details driver mechanics (snapshot timing, command position, env prefixing) that could partly live in the delegated skill, and repeats the 'only via Droid Control' rule twice.

4 / 5

Actionability

Nearly every flow gives a copy-paste-ready invocation with exact flags (e.g. "--type pdf --count 20 --output-path ./qa-results/$RUN_ID/data/standard") plus concrete expected values ("exactly 20 PDF Native Files", "CASE00000001 through CASE00000003", tolerance "0.0031 relative deviation"), and the build command is complete. Minor gaps keep it at anchor 4 rather than 5: "$TCTL" and "$session" are used but never defined here, flow 7 describes the Source CSV by column name without a literal example, and flow 10 uses placeholder paths like "<prior-dir>".

4 / 5

Workflow Clarity

A clear sequence (set RUN_ID → build when affected → choose flows → run via routed terminal → verify → capture evidence) with explicit per-flow "Verify..." checkpoints and a nine-item Known Failure Modes checklist; verification steps are present, so the batch-operation cap at 3 does not apply. It falls short of anchor 5 because there is no feedback loop for error recovery — nothing says what to do when a positive flow's Verify step fails beyond putting evidence in Notes.

4 / 5

Progressive Disclosure

Scored against the actual bundle: a single well-organized SKILL.md (~107 lines) with clear sections (Target and interaction, Build and workspace, numbered 12-flow menu, Known Failure Modes) and no nested or dead references. It does not reach anchor 5 because it exceeds the sub-50-line simple-skill threshold and the detailed 12-flow menu — the bulk of the file — is a candidate for a one-level-deep references file that would keep the SKILL.md overview leaner.

4 / 5

Total

16

/

20

Passed

Description

70%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 specific and unambiguous about its target: QA testing of the Zipper CLI across ten named feature areas, with strong distinctiveness from other skills. Its main weakness is the complete absence of a 'when to use' clause, which both caps completeness and leaves trigger coverage dependent on users already naming Zipper features. Adding an explicit usage trigger would move it firmly into strong territory.

Suggestions

Add an explicit trigger clause, e.g. "Use when the orchestrator needs to QA-test Zipper CLI changes, verify a CLI-path diff, or exercise Zipper's generation modes."

Include natural synonyms users might say, such as "regression tests", "test suite", or "smoke tests", alongside "QA tests".

State the deliverable briefly (e.g. "...and reports observed evidence per flow") so the 'what' covers the outcome, not just the exercised areas.

DimensionReasoningScore

Specificity

"QA tests for the Zipper CLI. Exercises Standard, Loadfile-Only, Chaos Engine, Production Set, Source-Driven Generation, Load File Formats, Archive Test Fixtures, Production Manifest comparison, version output, and CLI boundaries" names ten concrete, domain-specific test areas, which exceeds anchor 3's '1-2 concrete actions'. It falls short of anchor 5 because the action vocabulary is essentially a single generic verb ('Exercises') applied to objects, rather than multiple distinct concrete actions like 'extract', 'fill', and 'merge'.

4 / 5

Completeness

The 'what' is clear (QA testing of the Zipper CLI across ten named feature areas), but there is no "Use when..." clause or any equivalent explicit trigger guidance — 'when' is entirely absent, not merely weakly implied. Per the judging guidelines this caps completeness at 3; it cannot reach 4, which requires both 'what' and a present-but-imprecise 'when'.

3 / 5

Trigger Term Quality

"QA tests", "Zipper CLI", and distinctive feature names ("Chaos Engine", "Production Set", "Loadfile-Only", "Production Manifest comparison") are natural phrases a user would say when needing this skill. It sits at anchor 4 rather than 5 because common variations such as "regression tests", "test suite", or "smoke tests" are absent.

4 / 5

Distinctiveness Conflict Risk

The description is anchored to a specific named tool ("the Zipper CLI") with tool-unique triggers like "Chaos Engine", "Loadfile-Only", and "Archive Test Fixtures" — a clear niche with minimal risk of triggering for a different skill. Even the somewhat generic "QA tests" and "CLI boundaries" are qualified by the Zipper name, so anchor 5 fits better than anchor 4's 'minor overlap risk'.

5 / 5

Total

16

/

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.

Repository

dwojtaszek/zipper

Path

.factory/skills/qa-cli/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.