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

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 ./.agents/skills/receiving-code-review/SKILL.md
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 an exceptionally actionable behavioral policy with concrete phrasings, checklists, validation checkpoints, and feedback loops covering the full receive→verify→respond→implement cycle. Its main weakness is redundancy — key rules and one example are repeated across sections — which inflates token cost without adding guidance.

Suggestions

Deduplicate the "Fix 1-6" example, which appears nearly verbatim in "Handling Unclear Feedback" and again in "Real Examples" — keep one occurrence and cross-reference it.

Merge the overlapping restatements of the no-performative-agreement rule ("Forbidden Responses", "Acknowledging Correct Feedback", "Common Mistakes", "The Bottom Line") into a single authoritative section.

Consider moving the ✅/❌ reply templates and "Real Examples" into a references file so SKILL.md stays a lean overview.

DimensionReasoningScore

Conciseness

No tokens are spent explaining concepts Claude already knows — every line is user-specific policy — but the document repeats itself: the "Fix 1-6" unclear-items example appears nearly verbatim in both "Handling Unclear Feedback" and "Real Examples", and the no-performative-agreement / no-gratitude rule is restated across at least four sections. This fits anchor 3 (mostly efficient but could be tightened) rather than 4, where over-explanation would be only minor.

3 / 5

Actionability

For an instruction-only skill the guidance is fully concrete and copy-paste ready: exact forbidden phrases ("You're absolutely right!"), exact replacement phrasings ("I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."), a runnable grep-based YAGNI check, and a specific gh api command for GitHub thread replies, with ✅/❌ examples covering the common cases. This matches the top anchor.

5 / 5

Workflow Clarity

The multi-step process is clearly sequenced with explicit checkpoints: the 6-step READ→IMPLEMENT pattern, STOP-and-ASK on unclear items with a stated rationale, a 5-item verification checklist for external reviewers, and an implementation order that requires testing each fix individually and verifying no regressions. Feedback loops are present throughout (push back if wrong, say so if unverifiable, correct your own pushback factually), matching the top anchor.

5 / 5

Progressive Disclosure

The body is well-organized into clearly headed sections with no buried or nested references and no content that obviously belongs in another file for a cohesive behavioral policy. Not 5 because the skill exceeds the 50-line simple-skill threshold and a reference bundle (e.g. examples or the reply templates) could arguably be split out; not 3 because nothing is misplaced or poorly signaled — structure is good with only minor organization gaps.

4 / 5

Total

17

/

20

Passed

Description

62%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 clause and a distinct niche (receiving vs. performing reviews), but the capability side is defined only as a behavioral stance ("technical rigor and verification") without concrete actions, and trigger coverage relies on one main phrase. It is solid but leaves the reader inferring what the skill actually does.

Suggestions

Name the concrete capabilities in the description, e.g. "Verifies review suggestions against the codebase, asks clarifying questions on unclear items, and pushes back with technical reasoning when a suggestion is wrong" — this would raise both specificity and completeness.

Add natural trigger synonyms such as "review comments", "PR feedback", or "addressing reviewer suggestions" so users phrasing the need differently still match.

Consider dropping the trailing stance clause ("not performative agreement or blind implementation") if capability verbs are added, keeping the description lean while saying more.

DimensionReasoningScore

Specificity

The description names the domain ("receiving code review feedback, before implementing suggestions") and gestures at 1-2 actions ("verification", avoiding "blind implementation"), but never lists concrete capabilities such as verifying suggestions against the codebase, asking clarifying questions, or pushing back with reasoning. It matches anchor 3 (domain plus 1-2 actions, not comprehensive) rather than 4, which requires several specific listed actions.

3 / 5

Completeness

The "when" is explicit and strong ("Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable") and the "what" is present ("requires technical rigor and verification, not performative agreement or blind implementation"). Not 5 because the "what" states a behavioral stance rather than concretely naming what the skill does, so a reader must infer the actual capabilities.

4 / 5

Trigger Term Quality

"code review feedback" and "suggestions" are natural phrases a user would say, but common variations like "review comments", "PR feedback", or "addressing reviewer comments" are absent. This fits anchor 3 (some relevant keywords, missing common variations) more than 4, since coverage is concentrated in one main phrase rather than good multi-term coverage.

3 / 5

Distinctiveness Conflict Risk

"receiving code review feedback, before implementing suggestions" carves out a clear niche distinct from skills for performing or giving code reviews, with dedicated triggers. Not 5 because a bare utterance like "code review" could still plausibly route to a review-performing skill, leaving minor overlap risk with closely related skills.

4 / 5

Total

14

/

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

phatblat/dotfiles

Path

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