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

84

1.34x
Quality

76%

Does it follow best practices?

Impact

97%

1.34x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/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

73%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 well-structured, actionable behavioral skill with a clear sequenced workflow and explicit validation checkpoints for batch code-review changes. The main drag is redundancy — the same anti-patterns and no-gratitude rules are reinforced across multiple sections, adding tokens without adding new guidance.

Suggestions

Consolidate the repeated forbidden-phrase and no-gratitude rules into one 'Forbidden Responses' section and reference it elsewhere instead of restating 'You're absolutely right!' / 'Great point!' / 'Thanks' across four sections.

Merge the 'Common Mistakes' table into the relevant procedural sections (Handling Unclear Feedback, When To Push Back, Acknowledging Correct Feedback) to remove restated guidance.

Tighten abstract directives like 'Use technical reasoning, not defensiveness' into concrete patterns (e.g., 'cite the failing test or working code, then ask the specific question').

DimensionReasoningScore

Conciseness

The body is mostly efficient — it uses dense code blocks and tables and avoids explaining concepts Claude already knows — but the same forbidden anti-patterns ('You're absolutely right!', 'Great point!', the no-gratitude rule) recur across Forbidden Responses, Acknowledging Correct Feedback, Common Mistakes, and Real Examples, which could be tightened, fitting 'mostly efficient but includes some unnecessary explanation or could be tightened'.

3 / 5

Actionability

Concrete, actionable guidance dominates: copy-ready response templates, a real 'gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies' command, and 'grep codebase for actual usage'; a few directives stay abstract ('Use technical reasoning, not defensiveness'), keeping it at 'mostly executable guidance with minor gaps' rather than 5.

4 / 5

Workflow Clarity

A clear sequenced pattern (READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT) is paired with explicit validation checkpoints ('Test each fix individually', 'Verify no regressions', 'STOP - do not implement anything yet') and a feedback loop (Gracefully Correcting Your Pushback), matching the top anchor for batch/feedback workflows.

5 / 5

Progressive Disclosure

The single-file skill is well-organized into clearly headed sections with no need for external references, but at ~200 lines it exceeds the under-50-line simple-skill exception and has no one-level-deep references, while cross-section repetition of the same rules represents a minor organization gap, fitting 'good structure; most content appropriately placed; minor organization gaps'.

4 / 5

Total

16

/

20

Passed

Description

78%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 strong, explicit description that clearly states both purpose and trigger conditions with natural phrasing. Its main weakness is that the capabilities are expressed as a behavioral stance with some negative framing rather than a list of crisp concrete actions.

DimensionReasoningScore

Specificity

The description names the domain ('receiving code review feedback') and a couple of actions ('implementing suggestions', 'verification'), but the actions are framed partly negatively ('not performative agreement or blind implementation') and remain more behavioral stance than crisp concrete actions, matching the 'names domain and 1-2 concrete actions' anchor rather than the 4 anchor's 'several specific actions'.

3 / 5

Completeness

It explicitly answers both 'what' ('requires technical rigor and verification, not performative agreement or blind implementation') and 'when' ('Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable') with concrete trigger phrases, matching the top anchor.

5 / 5

Trigger Term Quality

Natural phrases a developer would say are well covered ('code review feedback', 'implementing suggestions', 'feedback seems unclear or technically questionable'), fitting the 'good keyword coverage; a few natural terms missing' anchor — synonyms like 'PR comments' or 'pull request review' are absent, keeping it below 5.

4 / 5

Distinctiveness Conflict Risk

The receiving-vs-giving-review framing carves a clear niche with distinct triggers, but 'before implementing suggestions' carries minor overlap risk with general code-editing skills, placing it at 'mostly distinct; minor overlap risk' rather than the 5 anchor's 'minimal conflict risk'.

4 / 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.

Validation16 / 16 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.