roborev-design-review

Use only when the user explicitly invokes /roborev-design-review

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./internal/skills/grok/roborev-design-review/SKILL.md

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.

The content is a strong, well-sequenced workflow: concrete executable commands, an explicit input-validation checkpoint, error-recovery guidance, and clear presentation/next-step instructions. Its only weaknesses are mild redundancy in the meta-commentary and examples, and a moderately long single file where troubleshooting and panel details could be split out.

Dimension	Reasoning	Score
Conciseness	The body is efficient and focused on roborev-specific knowledge Claude lacks (CLI flags, sandbox escalation, panel synthesis semantics), with only minor over-explanation — the "These instructions are guidelines, not a rigid script" meta-commentary and an Examples section that largely restates the instruction steps. Not anchor 5 because those sections could be trimmed.	4 / 5
Actionability	Fully executable, copy-paste-ready commands cover the common cases: `roborev review --wait --type design`, a heredoc snippet that validates the commit ref with `git rev-parse --verify --end-of-options` before invoking, concrete error-recovery commands (`roborev status`, `roborev init`), and the `/roborev-fix <job_id>` follow-up. Both HEAD and specific-commit invocations are shown.	5 / 5
Workflow Clarity	A clear four-step sequence with an explicit validation checkpoint (ref verification, "If validation fails... Do not proceed") and error-recovery feedback loops (report daemon/repo errors, suggest `roborev status` or `roborev init`, re-run). Branching for findings vs. pass and panel vs. single-agent reviews is explicit.	5 / 5
Progressive Disclosure	No bundle files exist, and the single file is well-organized with clear section headers, a See-also section pointing to sibling skills, and easy navigation. Not anchor 5 because at ~130 lines the secondary detail (panel synthesis semantics, sandbox troubleshooting) could live in a separate reference file — a minor organization gap rather than inlined bulk reference material.	4 / 5
	Total	18 / 20 Passed

Description

51%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 a deliberate explicit-invocation gate: unambiguous and conflict-free as a trigger, but it omits any statement of what the skill actually does (request a design review of a commit and present the verdict/findings). This makes it uninformative in skill listings even though the invocation gating is sound. Suggestions focus on adding the missing 'what'.

Suggestions

State the capability explicitly, e.g. "Request a design review of a commit via the roborev CLI and present the verdict and findings. Use only when the user explicitly invokes /roborev-design-review."

Include capability keywords ("design review", "commit", "verdict", "findings") so the description communicates the skill's function in listings and searches, not just its invocation constraint.

Briefly name the outcome — review verdict grouped by severity and an optional /roborev-fix follow-up — to make the 'what' concrete in one clause.

Dimension	Reasoning	Score
Specificity	"Use only when the user explicitly invokes /roborev-design-review" names the command but describes zero actions — no capability (requesting a design review, presenting results) is stated. It is not pure abstract language (the trigger is precise), so it sits between anchor 1 and anchor 3.	2 / 5
Completeness	Only the 'when' is present ("when the user explicitly invokes /roborev-design-review") without any 'what' — matching anchor 2's "only 'when' is present without 'what'". The 'when' itself is explicit and unambiguous, keeping it above anchor 1.	2 / 5
Trigger Term Quality	The trigger term is the literal slash command itself, exactly what a user would type to invoke it — good natural coverage with no missing synonyms. Not anchor 5 because there are no broader natural phrases (e.g. "design review a commit") that aid discovery in listings.	4 / 5
Distinctiveness Conflict Risk	Explicit-invocation-only gating gives it a clear niche with a distinct trigger and minimal conflict risk — it cannot fire in response to similar-sounding natural requests like "review this commit's design".	5 / 5
	Total	13 / 20 Passed

Validation

100%

Warnings & errors only

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: kenn-io/roborev
Path: internal/skills/grok/roborev-design-review/SKILL.md
Commit: a87c9af

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

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.