request-review

Route a change to a non-author local peer when local review is the selected independent validation source. Use when: risk routing chooses a stateful local reviewer for implementation, governance, or semantic context. Not for: cloud as the selected source, vision-guardian acceptance, self-check, or review feedback handling. Output: risk-matched review packet in the current thread/PR; mailbox archive only when the change needs the full packet.

Quality

61%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./cat-cafe-skills/request-review/SKILL.md

Quality

Content

56%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 delivers genuinely actionable review-routing guidance with concrete commands, templates, tool names, and explicit fail-closed validation checkpoints. Its main costs are heavy redundancy of policy caveats and a monolithic structure that inlines reference-grade detail instead of splitting it into bundled files.

Suggestions

Split reference-grade detail (verdict return-route rules, the R4 brake, and the scarce-seat engagement modes) into files under references/ and keep SKILL.md as a concise overview with one-level-deep links, which would serve both conciseness and progressive disclosure.

Consolidate the repeated boundary rules (no self-review, exact-HEAD evidence, no duplicate review sources, no re-entry of scarce reviewers) into a single 'Non-negotiables' table instead of restating them in the routing, packet, verdict, and feedback sections.

Add a short numbered workflow at the top (choose source -> assemble evidence -> send packet -> route verdict -> handle feedback) so the sequence does not have to be inferred from the section ordering.

Dimension	Reasoning	Score
Conciseness	The ~230-line body repeatedly restates the same boundary rules (no self-review, exact-HEAD/continuityProof, no re-entry of scarce reviewers, no duplicate review sources) across the routing, packet, verdict, and feedback sections, and much of the dossier/R4-brake/re-ack detail is policy nuance that could be compressed. It earns some credit for assuming domain knowledge (no basic-concept explanations), but the padding is noticeably above the midpoint of the scale. Not 3 because several sections could be cut or halved without losing executable guidance; not 1 because it never explains things Claude already knows.	2 / 5
Actionability	Concrete, executable material is abundant: git/rg artifact-check commands, an exact packet field template, named tools (cat_cafe_prepare_request_review_consumption, cat_cafe_get_thread_context, gh pr comment {N} --body-file <verdict.md>), sandbox path template, and pnpm review:start. Not 5 because a large share of the body (selection boundaries, scarce-seat policy, entry-mode classifier, R4 brake) is abstract policy prose with no executable artifact, leaving gaps between the concrete islands.	4 / 5
Workflow Clarity	The flow is well staged — source selection, a pre-request evidence table where every missing item has an explicit 'BLOCKED' action, packet depth choice, artifact checks, sandbox, verdict routing, and feedback loops — with fail-closed error recovery (re-ack fail closed, warn_open, Finding Pattern Summary after R4). Not 5 because the sequence must be inferred from section order rather than an explicit numbered workflow, and branches like the R4 brake and entry-mode classifier are genuinely hard to follow on first read.	4 / 5
Progressive Disclosure	Sections are clearly organized and the one external reference ([../.cat-cafe-shared-refs/review-request-template.md]) is one level deep and clearly signaled, but the body inlines roughly 200 lines of policy detail (verdict routing rules, R4 brake mechanics, scarce-seat engagement modes) that belongs in separate reference files; no references/, scripts/, or assets/ directories exist in the bundle. Not 2 because the structure is real and the one reference is properly signaled; not 4 because the bulk of the detail is monolithically inlined in SKILL.md.	3 / 5
	Total	13 / 20 Passed

Description

66%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 explicit about what it does, when to use it, and what it is not for, giving it excellent distinctiveness and solid completeness. Its weaknesses are jargon-heavy trigger language that users would not naturally say and a thin set of concrete capabilities.

Suggestions

Rewrite the 'Use when' clause with natural user-facing phrases (e.g., 'use when you want a second pair of eyes on a diff before merging') instead of internal routing vocabulary like 'risk routing chooses a stateful local reviewer'.

Surface the natural trigger phrases already present in the frontmatter 'triggers' field ('请 review', '帮我看看', 'request review') inside the description itself so the description alone carries natural keywords.

Add one or two more concrete actions to the what-statement (e.g., 'assemble the review packet, bind the exact HEAD SHA, and deliver the typed verdict') to broaden capability coverage.

Dimension	Reasoning	Score
Specificity	"Route a change to a non-author local peer" and "Output: risk-matched review packet in the current thread/PR; mailbox archive only when..." name the domain and 1-2 concrete actions, but there is no broader list of specific capabilities. Not 4 because the description describes essentially a single routing action rather than several specific actions with only minor gaps.	3 / 5
Completeness	Both what ("Route a change to a non-author local peer... risk-matched review packet") and when ("Use when: risk routing chooses a stateful local reviewer for...") are explicitly present, plus a "Not for:" exclusion list. Not 5 because the when-clause uses abstract routing criteria instead of concrete trigger phrases a user would say, and not 3 because the when guidance is explicit, not merely implied.	4 / 5
Trigger Term Quality	"local review" and "review packet" supply a relevant keyword, but the when-clause hinges on internal jargon ("risk routing chooses a stateful local reviewer for implementation, governance, or semantic context", "vision-guardian acceptance") rather than phrases a user would naturally say; common natural variations are missing from the description itself. Not 2 because a genuinely relevant natural term (review/local peer) is present; not 4 because most of the vocabulary is policy-internal.	3 / 5
Distinctiveness Conflict Risk	"Not for: cloud as the selected source, vision-guardian acceptance, self-check, or review feedback handling" draws explicit boundaries against adjacent skills, and the niche (non-author local peer review) is clearly delimited. Not 4 because the exclusions leave minimal overlap risk, going beyond 'minor overlap with closely related skills'.	5 / 5
	Total	15 / 20 Passed

Validation

87%

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 — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning
relative_links	Relative link issues: 1 suspicious	Warning

	Total	14 / 16 Passed

Repository: zts212653/clowder-ai
Path: cat-cafe-skills/request-review/SKILL.md
Commit: 61389cc

Reviewed: 2 hours 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.