CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

aw-verify

Proves a feature works end to end, locally or on the PR preview: reuses the brief and specs `/aw` wrote, gets the environment ready, probes it in the browser (ui-verify) with concurrency and fault cases, then reads what the services recorded (telemetry-verify), fixes what it finds on a local stack one commit per finding, and reports with real screenshots. `setup` writes the committed `.agents/aw/` config every suite skill reads. Triggers on "/aw-verify".

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

81%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 lean, well-sequenced orchestration card with concrete dispatch code, explicit feedback loops, and a definition of done — strong on token efficiency and workflow clarity. Its critical defect is progressive disclosure: it defers nearly all operative detail to a rules/ directory that is absent from the bundle, so as shipped the skill's navigation chain is broken and one of its two bundle files is orphaned.

Suggestions

Ship the rules/ directory (config.md, intent.md, local-stack.md, auth.md, browser-verification.md, findings.md, fix-loop.md, report.md, lessons.md, pr-comment.md, setup.md, delegation.md) or inline the essential content of each into SKILL.md — as delivered, every run-card step links to a file that does not exist, breaking the skill's navigation entirely.

Reference scripts/verify-comment.mjs from the body (e.g., in the PR-comment step pointing to rules/pr-comment.md, which should invoke it) so the only executable bundle asset is discoverable and its role is clear.

In the run card, name which placeholders each rule resolves (e.g., '<env> comes from environments.yml, <driver> from rules/local-stack.md') so a reader can act even when a referenced file cannot be loaded.

DimensionReasoningScore

Conciseness

The body is dense and operational — modes, a flag table, a numbered run card, verbatim dispatch code, and a Definition of Done checklist — with no padding and no explanation of concepts Claude already knows. Lines like 'Start it detached, logs to procs/<name>.log, poll the ready URL' pack maximal instruction into minimal tokens, matching the lean/efficient anchor; nothing reads as filler that would drop it to 4.

5 / 5

Actionability

The two-witness block gives copy-paste-ready Skill()/Agent() invocations with exact flags ('--env <env>', '--windows .agent/<branch>/verify/probes.jsonl', '--no-telemetry --no-comment'), and the run card specifies concrete artifacts (intent.md with 'AC-n' verbatim and tagged rows, probes.jsonl with 'window_start'/'window_end'/'log_offsets', findings.jsonl, procs/<name>.log). It stops short of fully executable because each step's operative detail is deferred to rules/*.md files and placeholders like <env> and <driver> are resolved by config rules not inlined, leaving minor gaps the body alone cannot close.

4 / 5

Workflow Clarity

The run card is an explicitly ordered 0-6 sequence ('Do these in order') with validation at each turn ('No .agents/aw/environments.yml, or no entry for the environment → run setup first; never guess'), a feedback loop for error recovery ('After a fix, re-run the probe that found it; stop at ✅ verified or at --loops'), defect routing ('record it, then route around it without changing code'), an explicit verdict rule, and a Definition of Done checklist. This matches the anchor requiring clear sequence, explicit validation, feedback loops, and checklists; nothing about the batch/fix operations lacks verification.

5 / 5

Progressive Disclosure

The body is structured as a good overview with well-signaled one-level-deep links (rules/config.md, rules/intent.md, rules/fix-loop.md, etc.), but scored against the actual bundle: 12 of the 13 referenced paths (the entire rules/ directory) do not exist — only references/design.md is present — and the shipped scripts/verify-comment.mjs is never referenced from the body. Every run-card step points to a missing file, so navigation is broken rather than merely imperfect, fitting the minimal/broken-structure anchor rather than 3 (where references exist but are poorly organized).

2 / 5

Total

16

/

20

Passed

Description

76%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 specific, artifact-anchored description that comprehensively covers what the skill does across setup, browser probing, telemetry, fixing, and reporting. Its weaknesses are the 'when' side: the only trigger is the literal '/aw-verify' command, with no natural-language trigger phrases or synonyms, so a user describing the need in plain words may not match it.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions covering the full lifecycle: 'Proves a feature works end to end, locally or on the PR preview', 'probes it in the browser (ui-verify) with concurrency and fault cases', 'reads what the services recorded (telemetry-verify)', 'fixes what it finds on a local stack one commit per finding', 'reports with real screenshots', and 'setup writes the committed .agents/aw/ config'. These are specific, artifact-level actions with named sub-skills and outputs, matching the comprehensive-coverage anchor; it is not the score-4 anchor because there is no noticeable coverage gap across setup, probe, telemetry, fix, and report.

5 / 5

Completeness

The 'what' is comprehensive (probe, telemetry, fix, report with the artifacts each produces), and an explicit 'when' exists ('Triggers on "/aw-verify"'), so it is not capped at 3 for missing trigger guidance. It falls short of the score-5 anchor because the 'when' is a single narrow command rather than concrete natural-language trigger phrases like 'Use when asked to verify a feature end to end' — the trigger could be more explicit about the situations that call for this skill.

4 / 5

Trigger Term Quality

Relevant keywords exist ('Proves a feature works', 'end to end', 'verify', 'PR preview', 'screenshots') but the only explicit trigger is the literal command 'Triggers on "/aw-verify"', and natural variations users would say ('test the feature', 'e2e', 'check that it works', 'QA the PR') are missing. It sits at the some-keywords-but-missing-synonyms anchor rather than 4 because keyword coverage is thin outside the slash command itself, and rather than 2 because the terms present are ones a user with this workflow would naturally use.

3 / 5

Distinctiveness Conflict Risk

It carves a clear niche — end-to-end verification inside the '/aw' suite, coordinating 'ui-verify' and 'telemetry-verify' over a '.agents/aw/' config — with a distinct trigger ('/aw-verify'). The suite-specific vocabulary and dedicated command give minimal conflict risk with generic verify/test/review skills, matching the clear-niche-with-distinct-triggers anchor rather than the minor-overlap anchor at 4.

5 / 5

Total

17

/

20

Passed

Validation

81%

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

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_field

'metadata' should map string keys to string values

Warning

frontmatter_unknown_keys

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

Warning

relative_links

Relative link issues: 16 missing

Warning

Total

13

/

16

Passed

Repository

mthines/agent-skills

Path

skills/testing/aw-verify/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.