CtrlK
BlogDocsLog inGet started
Tessl Logo

receiving-code-review

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

65

Quality

77%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./eval/local/skills/benchmarks/dependency/superpowers/receiving-code-review/SKILL.md

The canonical home for this skill is receiving-code-review in obra/superpowers

SKILL.md
Quality
Evals
Security

Quality

Content

81%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 strong instruction-style skill body: the response workflow is explicitly sequenced with validation checkpoints, and the guidance is copy-paste concrete with good and bad response templates. The main cost is token efficiency — several rules and examples are repeated across sections and could be consolidated.

Suggestions

Consolidate the repeated no-gratitude/no-performative-agreement rules: 'Forbidden Responses', 'Acknowledging Correct Feedback', 'Common Mistakes', and 'Real Examples' all restate the same prohibition; state it once and cross-reference.

Remove the duplicated 'Fix 1-6' / items 1-6 unclear-feedback example — it appears nearly verbatim in both 'Handling Unclear Feedback' and 'Real Examples'.

Trim the 'Real Examples' section to only cases not already illustrated inline (the YAGNI and legacy-code examples earn their tokens; the duplicated unclear-item and performative-agreement ones do not).

DimensionReasoningScore

Conciseness

The body is dense and rule-driven rather than padded with concepts Claude already knows, but there is real duplication: the 'Fix 1-6' unclear-items example appears in both 'Handling Unclear Feedback' and 'Real Examples', and the no-gratitude/no-performative-agreement rule is restated across 'Forbidden Responses', 'Acknowledging Correct Feedback', 'Common Mistakes', and 'Real Examples'. This fits anchor 3 (mostly efficient but could be tightened) rather than 4, where only minor trims would be needed.

3 / 5

Actionability

Guidance is fully concrete: exact ✅/❌ response templates, a specific gh api command for GitHub thread replies ('gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies'), and a grep-before-implement YAGNI procedure. Specific examples cover the common cases, matching anchor 5; it is not anchor 4 because there are no meaningful gaps in executable guidance.

5 / 5

Workflow Clarity

A clear 6-step sequence (READ, UNDERSTAND, VERIFY, EVALUATE, RESPOND, IMPLEMENT) with explicit validation checkpoints ('Test each fix individually', 'Verify no regressions'), prioritized implementation order (blocking issues first), and feedback loops for error recovery (the 'Gracefully Correcting Your Pushback' section plus the Common Mistakes checklist). Matches anchor 5.

5 / 5

Progressive Disclosure

Content is organized into clear single-level sections with no nested or dangling references (no bundle files exist and none are referenced, so there are no dead links). It is not anchor 5 because the skill is ~210 lines with example-heavy sections that could be split or trimmed, and not anchor 3 because nothing is buried or misfiled — matching anchor 4's 'good structure, minor organization gaps'.

4 / 5

Total

17

/

20

Passed

Description

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

A well-targeted description with an explicit 'Use when' clause, natural trigger language, and a distinct niche. Its main weakness is that the capability side is stated as a behavioral requirement rather than a list of concrete actions, and it lacks common trigger synonyms.

Suggestions

Add 2-3 concrete capabilities to the description, e.g. 'Restate feedback, verify suggestions against the codebase, and push back with technical reasoning when review comments are wrong.'

Include common trigger synonyms such as 'PR comments', 'reviewer feedback', or 'code review comments' so users' natural phrasing matches the skill.

State the what as capabilities Claude performs rather than only as requirements ('requires technical rigor') to sharpen the completeness of the description.

DimensionReasoningScore

Specificity

Names the domain ('receiving code review feedback') and the required stance ('technical rigor and verification, not performative agreement or blind implementation') but lists few concrete actions such as restating feedback, verifying against the codebase, or pushing back. It matches anchor 3: domain plus 1-2 concrete actions, not comprehensive.

3 / 5

Completeness

Both parts are present: an explicit 'Use when receiving code review feedback, before implementing suggestions' trigger and a what-framed requirement ('requires technical rigor and verification...'). The 'what' is expressed as a requirement rather than a concrete capability list, so it fits anchor 4 rather than the fully concrete anchor 5.

4 / 5

Trigger Term Quality

Natural phrases like 'code review feedback', 'implementing suggestions', 'unclear', and 'technically questionable' are present, but common variations users would say ('PR comments', 'reviewer feedback', 'code review comments') are missing. Good coverage without being comprehensive, so anchor 4 rather than 5.

4 / 5

Distinctiveness Conflict Risk

'Receiving code review feedback' occupies a clear niche distinct from skills about giving reviews or general coding, and the negative triggers ('not performative agreement or blind implementation') further disambiguate. Minimal conflict risk, matching anchor 5.

5 / 5

Total

16

/

20

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
rpamis/comet
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.