CtrlK
BlogDocsLog inGet started
Tessl Logo

requesting-code-review

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

36

Quality

31%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/requesting-code-review/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

62%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured skill that clearly communicates when and how to request code reviews, with good workflow integration guidance and a practical example. Its main weaknesses are slightly vague dispatch instructions (missing exact tool invocation syntax) and some unnecessary advisory content that Claude wouldn't need. The referenced template file is not provided in the bundle, limiting verification of progressive disclosure.

Suggestions

Show the exact Task tool invocation syntax for dispatching the code-reviewer subagent, rather than describing it abstractly

Trim the 'Red Flags' section — Claude doesn't need to be told not to ignore critical issues or skip reviews; focus on the non-obvious guidance

Include the referenced code-reviewer.md template in the bundle or inline the template format so the skill is self-contained

DimensionReasoningScore

Conciseness

Generally efficient but has some unnecessary padding — the 'Red Flags' section with 'Never skip review because it's simple' and similar advice is somewhat obvious for Claude. The 'Core principle: Review early, review often' tagline and some workflow integration descriptions could be tightened.

2 / 3

Actionability

Provides concrete bash commands for getting SHAs and a clear placeholder template, but the actual dispatch mechanism is vague ('Use Task tool with superpowers-ruby:code-reviewer type, fill template at code-reviewer.md') — it doesn't show the exact invocation syntax. The example is illustrative but not fully copy-paste executable.

2 / 3

Workflow Clarity

The three-step process (get SHAs → dispatch reviewer → act on feedback) is clearly sequenced with explicit prioritization of feedback types (Critical → fix immediately, Important → fix before proceeding, Minor → note for later). The feedback loop of fix-then-continue is well articulated, and integration with different workflow contexts is clearly mapped.

3 / 3

Progressive Disclosure

References a template at 'requesting-code-review/code-reviewer.md' but no bundle files are provided, so we can't verify the reference works. The content is reasonably structured with clear sections, but the example section is quite long and could potentially be in a separate file. The reference to the template is mentioned both inline and at the end, which is good signaling.

2 / 3

Total

9

/

12

Passed

Description

0%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This description is critically weak because it only vaguely describes when to use the skill without ever explaining what the skill actually does. The language is entirely generic—'completing tasks', 'implementing major features', 'verify work meets requirements'—providing no concrete actions, no domain specificity, and no distinguishing trigger terms. It would be nearly impossible for Claude to correctly select this skill from a pool of alternatives.

Suggestions

Add a clear 'what' clause describing the specific actions this skill performs (e.g., 'Runs test suites, validates code coverage, and checks linting rules' or 'Generates a verification checklist against acceptance criteria').

Replace generic phrases like 'completing tasks' and 'implementing major features' with specific, natural trigger terms users would actually say (e.g., 'run tests', 'check requirements', 'pre-merge validation', 'QA check').

Restructure to follow the pattern: '[Concrete actions]. Use when [specific triggers].' to ensure both what and when are explicitly covered.

DimensionReasoningScore

Specificity

The description uses vague language like 'completing tasks' and 'implementing major features' without specifying any concrete actions. It doesn't describe what the skill actually does—only when to use it.

1 / 3

Completeness

The description addresses 'when' (before merging, when completing tasks) but completely fails to answer 'what does this do'. There is no indication of the skill's actual capabilities or actions.

1 / 3

Trigger Term Quality

The terms 'completing tasks', 'implementing major features', and 'merging' are extremely generic. 'Verify work meets requirements' is slightly more specific but still lacks natural keywords a user would say. There are no distinctive trigger terms.

1 / 3

Distinctiveness Conflict Risk

Phrases like 'completing tasks' and 'implementing major features' are so generic they could apply to virtually any skill. This would conflict with nearly every other skill in a collection.

1 / 3

Total

4

/

12

Passed

Validation

100%

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

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
lucianghinda/superpowers-ruby
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.