CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.tessl/plugins/obra/superpowers/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

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.

The body is a highly actionable, well-sequenced behavioral skill with explicit validation checkpoints, error-recovery loops, and ready-to-use response phrasings. Its main weakness is redundancy — the same rules and examples reappear across three to four sections, inflating token cost without adding guidance.

Suggestions

Merge the duplicated forbidden-phrase lists ("Forbidden Responses", "Acknowledging Correct Feedback", "Real Examples") into a single do/don't section and drop the "Common Mistakes" table that restates them.

Cut the "Real Examples" section's repeats ("Fix items 1-6", performative agreement) and keep only the two examples not already shown elsewhere (Technical Verification, YAGNI).

Trim coaching asides ("They'll appreciate your honesty", "If you catch yourself about to write 'Thanks': DELETE IT") that restate the preceding rule.

DimensionReasoningScore

Conciseness

The body avoids explaining concepts Claude already knows, but is noticeably repetitive: forbidden phrases ("You're absolutely right!", "Great point!", any gratitude) appear in both "Forbidden Responses" and "Acknowledging Correct Feedback", the "Fix 1-6" unclear-items example appears in both "Handling Unclear Feedback" and "Real Examples", and the "Common Mistakes" table restates prior sections. Not 2 because all content is skill-specific prescriptive guidance rather than known-concept padding; not 4 because the duplication is more than minor.

3 / 5

Actionability

As an instruction-only skill the guidance is copy-paste ready: the six-step READ/UNDERSTAND/VERIFY/EVALUATE/RESPOND/IMPLEMENT pattern, ready-made replies ("I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."), the grep-based YAGNI check, and a concrete command (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies). Specific examples cover the common cases with no significant gaps. Not 4 because coverage is comprehensive.

5 / 5

Workflow Clarity

The process is clearly sequenced with explicit validation ("Test each fix individually", "Verify no regressions"), a five-point verification checklist for external reviewers, STOP/ASK gates for unclear feedback, and a feedback loop for error recovery in "Gracefully Correcting Your Pushback". The batch-implementation context includes validation, so the missing-validation cap does not apply. Not 4 because checkpoints and recovery loops are explicit rather than minor-gap.

5 / 5

Progressive Disclosure

A single-file skill (no references/, scripts/, or assets/ bundle exists) organized under clear, well-navigable headers ("The Response Pattern", "Source-Specific Handling", "Implementation Order"). Not 5 because at ~200 lines it exceeds the simple-skill threshold and sections like "Real Examples" and "Common Mistakes" restate inlined content that could be trimmed or split out; not 3 because nothing is buried and the structure is easy to navigate.

4 / 5

Total

17

/

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 has an explicit, well-qualified trigger ("Use when receiving code review feedback... especially if feedback seems unclear or technically questionable") and a distinct niche, but describes capabilities as constraints rather than concrete positive actions. Trigger coverage is good though it lacks common synonyms like "PR comments" or "reviewer feedback".

Suggestions

State concrete positive actions (e.g., "verifies review suggestions against the codebase, clarifies unclear items before implementing, pushes back with technical reasoning when suggestions are wrong") instead of framing the what as "not performative agreement or blind implementation".

Add natural trigger synonyms such as "PR review comments", "reviewer feedback", or "responding to review suggestions" to broaden keyword coverage.

Tighten the constraint clause so the description leads with what the skill does and keeps the manner guidance as a short qualifier.

DimensionReasoningScore

Specificity

Names the domain ("receiving code review feedback") and 1-2 actions ("verification", "before implementing suggestions"), but capabilities are framed mostly as constraints ("not performative agreement or blind implementation") rather than concrete actions such as verifying suggestions against the codebase or pushing back with technical reasoning. Not 4 because it does not list several specific actions; not 2 because it goes beyond a bare domain label.

3 / 5

Completeness

The "when" is explicit with trigger conditions ("Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable"), and a "what" is present ("requires technical rigor and verification"), but the what is stated as behavioral constraints with negatives rather than a positive capability statement. Not 5 because the what-it-does is not crisply enumerated; not 3 because the when is explicit, not merely implied.

4 / 5

Trigger Term Quality

"code review feedback", "implementing suggestions", "unclear", and "technically questionable" are natural phrases a user would say when needing this skill, though common variations like "PR comments", "reviewer feedback", or "review suggestions" are missing. Not 5 because synonym/variation coverage is incomplete; not 3 because it includes more than generic domain keywords.

4 / 5

Distinctiveness Conflict Risk

"receiving code review feedback, before implementing suggestions" carves a distinct niche (responding to reviews rather than performing them or writing code generally). Not 5 because "code review" as a trigger could collide with skills that execute code reviews or manage PR replies; not 3 because the receiving/verification framing is quite specific.

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

chandler767/WorkJournal

Path

.tessl/plugins/obra/superpowers/skills/receiving-code-review/SKILL.md

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.