CtrlK
BlogDocsLog inGet started
Tessl Logo

verify

Prove a RuView result is real — run the deterministic SHA-256 proof and the witness bundle (ADR-028), and lint any claim for MEASURED-vs-CLAIMED honesty.

64

Quality

77%

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 ./harness/ruview/.claude/skills/verify/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

96%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 model of lean, high-actionability instruction: concrete commands, explicit pass/fail gates, and a regeneration feedback loop, with no padding or redundant explanation. The only weakness is mild — dense project-specific evidence inlined in the body with no signal for where extended detail lives.

DimensionReasoningScore

Conciseness

The body is lean and imperative throughout — "Must print VERDICT: PASS", "If numpy/scipy changed the hash, regenerate with verify.py --generate-hash then re-verify" — with no filler and no explanation of concepts Claude already knows; every token carries project-specific information.

5 / 5

Actionability

Guidance is copy-paste ready: "ruview_verify runs archive/v1/data/proof/verify.py", "bash scripts/generate-witness-bundle.sh", "cd dist/witness-bundle-ADR028-*/ && bash VERIFY.sh", and "ruview_claim_check {text}" are all concrete, executable commands with expected outcomes stated.

5 / 5

Workflow Clarity

Each procedure has an explicit validation checkpoint ("Must print VERDICT: PASS", "must be 7/7 PASS") plus a real error-recovery feedback loop (regenerate the hash then re-verify), and the firmware section states a hard release gate — matching the anchor for clear sequencing with explicit validation and feedback loops.

5 / 5

Progressive Disclosure

Four well-organized sections keep the ~40-line body navigable and appropriately short, but it inlines dense evidence detail (the ADR-028 manifest contents, the esp32 boot-log example) and references project-internal paths with no pointer to where a reader could go deeper — a minor organization gap rather than the clean split of a level-5 layout.

4 / 5

Total

19

/

20

Passed

Description

58%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 appropriately concise, naming three concrete capabilities in third person, but it omits any explicit trigger guidance and leans on project-specific jargon that limits natural keyword matching. Adding a "Use when..." clause with common trigger phrases would lift both completeness and trigger-term quality.

Suggestions

Append an explicit trigger clause, e.g. "Use when a RuView report, README accuracy claim, or release attestation needs to be verified or reproduced before shipping."

Include natural user-facing synonyms ("verify", "validate", "reproduce", "re-verify an accuracy claim") so the description matches how users actually phrase the request, not just internal jargon like "witness bundle (ADR-028)".

Briefly mention the firmware-specific capability (hardware validation requires a captured boot log on real silicon) so the description covers the full scope of the skill.

DimensionReasoningScore

Specificity

The description lists several concrete third-person actions — "run the deterministic SHA-256 proof", "the witness bundle (ADR-028)", "lint any claim for MEASURED-vs-CLAIMED honesty" — but stops short of comprehensive coverage (e.g., the firmware/boot-log validation capability from the body is absent).

4 / 5

Completeness

The "what" is clear (run the proof, the witness bundle, and the claim lint), but there is no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3 per the rubric guidelines.

3 / 5

Trigger Term Quality

"Prove", "real", and "honesty" are semi-natural terms, but coverage skews toward project jargon ("RuView", "ADR-028", "witness bundle") and misses common variations a user would naturally say, such as "verify", "validate", "reproduce", or "check this claim".

3 / 5

Distinctiveness Conflict Risk

"RuView result", "ADR-028", and "SHA-256 proof" carve out a distinct niche with minimal conflict risk, but the generic prove/verify framing leaves minor overlap with general verification or code-review skills.

4 / 5

Total

14

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

15

/

16

Passed

Repository
ruvnet/RuView
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.