CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

verify-zipper-change

Use when about to claim a Zipper change is done, fixed, or passing, especially for CLI behavior, Load File formats, Production Sets, or output bytes, to gather real-artifact evidence before the claim.

Quality

85%

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

SKILL.md
Quality
Evals
Security

Quality

Content

88%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.

An exemplary operational gate skill: fully executable commands, a clearly sequenced verify-inspect-parity-report workflow with explicit feedback loops, and tight, motivation-free prose. The only real gaps are a slightly doubled opening motivation and unpathed references to repo-level Critical Rules.

DimensionReasoningScore

Conciseness

The body is lean and imperative with zero basic-concept padding ("A gate that did not print green is not green", "Look at the bytes"), but the two opening paragraphs state the same look-at-real-output motivation twice, which is a minor trimmable instance of over-explanation. Anchor 4 fits better than 5, which demands every token earn its place.

4 / 5

Actionability

Every step is copy-paste executable with concrete flags and values: `./dev.sh --dry-run`, the full `dotnet run ... --seed 42 --output-path "$OUT"` invocation, `unzip -l`/`unzip -p`/`xxd` inspection, `dotnet publish` plus `ZIPPER_CLI=... run-goldens.sh`, and a named `--capture --scenario pdf-metadata` example. This matches anchor 5 (fully executable, common cases covered).

5 / 5

Workflow Clarity

Five clearly sequenced sections with explicit validation checkpoints ("Hashes must match", "Then open what it produced"), an explicit feedback loop ("Fix the root cause, rerun the same gate"), a defined failure-reporting protocol, and a red-flags checklist. This matches anchor 5; the destructive/batch cap does not apply because validation and parity checks are thoroughly specified.

5 / 5

Progressive Disclosure

Sections are well-organized and the skill is appropriately self-contained with no nested references, but at roughly 93 body lines it exceeds the under-50-line simple-skill threshold, and "Critical Rule 6" and "Critical Rule 4 (README, Requirements, glossary, E2E scripts)" are invoked without paths or links to where they live. Anchor 4 (good structure, minor organization gaps) fits better than 5.

4 / 5

Total

18

/

20

Passed

Description

73%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 well-scoped, distinctive trigger description with an explicit 'Use when' clause and natural trigger phrases. Its main weakness is that the 'what' half reduces to a single abstract action ("gather real-artifact evidence") without naming the concrete verification steps the skill actually performs.

Suggestions

State the concrete actions in the 'what' half, e.g., 'run the affected dev.sh gates, execute the CLI with a fixed seed, inspect the produced archive/DAT bytes, and compare golden manifests' instead of the generic 'gather real-artifact evidence'.

Add natural trigger variations such as 'verified', 'tests are green', or 'before marking a PR ready' to broaden the natural-phrase coverage.

Consider naming the two headline outcomes (gate parity and byte-level inspection) so the description previews the skill's two core activities.

DimensionReasoningScore

Specificity

The only stated action is "to gather real-artifact evidence before the claim"; the domain is well-named ("CLI behavior, Load File formats, Production Sets, or output bytes") but the description never lists concrete verification actions like running gates, inspecting output bytes, or comparing golden manifests. This matches anchor 3 (names domain and 1-2 concrete actions) rather than 4, which requires several specific actions.

3 / 5

Completeness

The 'when' is explicit and strong ("Use when about to claim a Zipper change is done, fixed, or passing"), and a 'what' is present ("to gather real-artifact evidence"), but the 'what' is generic rather than concrete. Anchor 4 fits (both present, one could be more specific); anchor 5 requires both to be clearly and concretely stated.

4 / 5

Trigger Term Quality

"done, fixed, or passing" are natural trigger phrases paired with concrete contexts ("claim a Zipper change", "CLI behavior", "output bytes"), giving good keyword coverage. A few natural terms are missing (e.g., "verified", "green", "tests pass"), so it falls just under anchor 5's comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

The description is scoped to "a Zipper change" with project-specific artifacts ("Load File formats, Production Sets"), creating a clear niche with distinct triggers and minimal conflict risk with other skills, matching anchor 5.

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

.agents/skills/verify-zipper-change/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.