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

60

Quality

68%

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

67%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 is a well-structured, highly actionable behavioral skill with clear workflows, validation checkpoints, and concrete example phrasing. Its main weakness is repetition of the same anti-performative-agreement rule across several sections, inflating token cost.

Suggestions

Consolidate the repeated 'no thanks / no performative agreement' guidance into one section (e.g. Forbidden Responses) and reference it once elsewhere instead of restating full ✅/❌ lists in Acknowledging Correct Feedback, Common Mistakes, Real Examples, and The Bottom Line.

Tighten the Real Examples section to two representative cases (e.g. technical verification and YAGNI) since the others restate patterns already shown in Handling Unclear Feedback.

Make the YAGNI and verification procedures slightly more concrete by naming the actual command form (e.g. 'grep -r <symbol> src/') rather than 'grep codebase for actual usage'.

DimensionReasoningScore

Conciseness

It avoids explaining concepts Claude already knows and uses terse procedure blocks, but the anti-performative-agreement / 'no thanks' rule is restated across roughly five sections (Forbidden Responses, Acknowledging Correct Feedback, Common Mistakes, Real Examples, The Bottom Line), which is padding that could be tightened.

3 / 5

Actionability

Provides concrete, copy-ready guidance: exact forbidden phrases ('You're absolutely right!'), exact replacement phrases, and ✅/❌ example dialogues covering common cases, though some procedures like 'grep codebase for actual usage' stay high-level.

4 / 5

Workflow Clarity

Sequences are clear (READ→UNDERSTAND→VERIFY→EVALUATE→RESPOND→IMPLEMENT; Implementation Order blocking→simple→complex) with explicit validation ('VERIFY', 'test each fix individually', 'verify no regressions') and a feedback loop ('Gracefully Correcting Your Pushback'), with only minor checkpoint gaps.

4 / 5

Progressive Disclosure

Single cohesive file with well-organized section headers and no external bundle files; the behavioral content is appropriately kept inline rather than split, though it runs ~210 lines with no progressive offloading of detail.

4 / 5

Total

15

/

20

Passed

Description

70%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 clearly states when to trigger the skill and its core disposition, with natural trigger terms and a distinct niche. Its weakness is that the 'what' is framed as abstract behavior rather than concrete, enumerable actions.

Suggestions

Replace abstract dispositions ('technical rigor and verification') with concrete actions, e.g. 'Verify each suggestion against the codebase, push back with technical reasoning, and implement one item at a time with tests.'

Add common trigger synonyms such as 'PR comments', 'review comments', or 'reviewer feedback' to broaden natural-language matching.

DimensionReasoningScore

Specificity

Names the domain ('receiving code review feedback') and a couple of behaviors ('technical rigor and verification', rejecting 'blind implementation'), but the actions are abstract dispositions rather than concrete operations, so it is not comprehensive.

3 / 5

Completeness

Has an explicit 'Use when...' trigger clause and states the 'what' (requires technical rigor and verification, not performative agreement or blind implementation), but the 'what' is a disposition rather than concrete actions, so it could be more specific.

4 / 5

Trigger Term Quality

Includes natural phrases a user would say ('code review feedback', 'implementing suggestions', 'feedback seems unclear or technically questionable'), though a few common variants like 'PR comments' or 'review comments' are missing.

4 / 5

Distinctiveness Conflict Risk

Targets a clear niche ('receiving code review feedback') with distinct trigger language, with only minor overlap risk against a broad general code-review skill.

4 / 5

Total

15

/

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