requesting-code-review

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Quality

52%

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 ./skills/requesting-code-review/SKILL.md

Quality

Content

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

A tight, well-sequenced instruction skill with concrete commands, a useful worked example, and explicit feedback triage rules. Its main defects are the dangling code-reviewer.md reference (the reviewer prompt template is missing from the bundle, undermining both actionability and navigation) and the absence of a re-review loop after fixes.

Suggestions

Add the referenced code-reviewer.md template file to the bundle (or inline its prompt) — it is cited twice but does not exist

Add an explicit re-review step after fixes (re-dispatch the reviewer on the new HEAD_SHA) to close the feedback loop

Trim the Common Rationalizations table or the worked example — one of the two carries most of the value

Dimension	Reasoning	Score
Conciseness	The body is lean: executable git commands, terse bullet lists, no explanation of concepts Claude already knows. The 'Common Rationalizations' table and the full worked example add tokens that could be trimmed, but they carry genuine anti-pattern value. Efficient with minor over-explanation → anchor 4, not 5.	4 / 5
Actionability	SHA commands are copy-paste ready and placeholders are defined, but the central artifact — the reviewer prompt template at [code-reviewer.md](code-reviewer.md) — does not exist in the bundle, so the actual dispatch step cannot be executed as written. Concrete guidance is present but incomplete with a missing key detail → anchor 3, not 4.	3 / 5
Workflow Clarity	The three-step sequence (get SHAs → dispatch reviewer → act on feedback) is clearly ordered, with explicit triage rules ('Fix Critical issues immediately', 'Fix Important issues before proceeding') and an error-recovery path for a wrong reviewer. Not destructive/batch, so no validation cap applies. Minor gap: no explicit re-review loop after fixes → anchor 4, not 5.	4 / 5
Progressive Disclosure	Sections are well-organized and the reference is one level deep and clearly signaled, but code-reviewer.md is referenced twice and is absent from the bundle — navigation is broken, and per the judging guidelines progressive_disclosure is scored against the actual bundle structure. Reference present but non-functional → anchor 3, not 4.	3 / 5
	Total	14 / 20 Passed

Description

41%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 has strong explicit 'when' triggers but a vague 'what' — it never states the skill's core capability (dispatching a code reviewer subagent) and omits the phrase 'code review' entirely. Its trigger on generic task completion creates conflict risk with any verification or testing skill.

Suggestions

State the core action in the description, e.g. 'Dispatch a code reviewer subagent with the diff between two commits to verify work meets requirements'

Add the natural trigger phrase 'code review' / 'review my changes' that users would actually say when they need this skill

Narrow the trigger from 'completing tasks' (fires on everything) to specific moments: after finishing a task, before merging, or when the user asks for a code review

Dimension	Reasoning	Score
Specificity	The only action phrase is 'verify work meets requirements', which is generic; no concrete actions like 'dispatch a code reviewer subagent' or 'review the diff' are named. Names a domain (verifying work) but actions are minimal — matching anchor 2, not 3 (which requires 1-2 concrete actions).	2 / 5
Completeness	The 'when' is explicit ('Use when completing tasks, implementing major features, or before merging') but the 'what' is weak — 'to verify work meets requirements' says nothing about dispatching a reviewer subagent. Not anchor 2 ('only when present without what') because a what exists, but not anchor 4 since the what is too vague to stand on its own.	3 / 5
Trigger Term Quality	'completing tasks', 'implementing major features', and 'before merging' are phrases users would naturally say. Missing common variations and synonyms: 'code review', 'review my changes', 'review the diff', 'before committing'. Some relevant keywords but missing variations → anchor 3, not 4 (which requires good coverage with only a few gaps).	3 / 5
Distinctiveness Conflict Risk	'Use when completing tasks' would trigger on nearly any completed task, giving high overlap risk with any verification, testing, or QA skill. The description never mentions 'code review', the skill's actual niche. Very broad with high overlap risk → anchor 2; not 3 because no distinctly ownable trigger phrase is present.	2 / 5
	Total	10 / 20 Passed

Validation

93%

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

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 2 missing	Warning

	Total	15 / 16 Passed

Repository: obra/superpowers
Path: skills/requesting-code-review/SKILL.md
Commit: 8ca22db

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.