CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

receiving-pr-reviews

Assess and address review feedback on GitHub PRs, GitLab MRs, or in conversation. Use when checking new reviews, responding to comments, rechecking after a push, or following up on approvals and change requests.

72

Quality

90%

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

SKILL.md
Quality
Evals
Security

Quality

Content

92%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-engineered skill body: token-efficient, clearly sequenced with validation gates and recovery loops, and cleanly split across one-level-deep references verified against the actual bundle. The only soft spot is that core process steps are stated as terse directives whose concrete execution lives in the reference files.

DimensionReasoningScore

Conciseness

Lean procedural prose with zero padding and no explanations of concepts Claude already knows; every sentence carries operational content (e.g., "A request to check reviews permits reading and reporting. Source edits, pushes, provider replies, and resolutions require user authorization"). Density occasionally borders on terse, but that is a readability tradeoff, not token waste.

5 / 5

Actionability

Names the concrete preferred tool ("scripts/pr_review_threads.py", "Consult its --help"), fallback CLIs (gh, glab), and scenario-specific reference files with links. Not 5 because several process steps are abstract directives ("implement the smallest coherent response at the owning seam") whose execution detail is deferred to references; not 3 because the tool routing and reference navigation are directly executable, and as an instruction-only skill the absence of code is not penalized.

4 / 5

Workflow Clarity

Five clearly numbered steps with explicit validation checkpoints: "verifying actual runtime consequences and regressions", "verify that the response appears and addresses the latest input", pre-mutation refresh of "the current target, inputs, thread states, and relevant remote revision", and a Recheck step with an explicit completion condition. The Recovery section supplies feedback loops ("preserve confirmed effects and retry only the remaining work after refreshing"), so the batch/destructive validation cap does not apply.

5 / 5

Progressive Disclosure

A ~33-line overview with four well-signaled, one-level-deep references, each linked with a stated purpose ("For GitLab-specific approval and discussion behavior, read GitLab review operations"); all referenced files exist in the bundle with real content and no nested second-level references. Details are appropriately split out, and the scripts directory is entered through a single documented helper. Only trivial nit: references/superpowers-license.txt is never linked.

5 / 5

Total

19

/

20

Passed

Description

83%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 description with explicit what-and-when structure, natural trigger phrases, and concrete platform scoping. Its main weaknesses are broad core verbs ("assess and address") and missing common synonyms ("code review", spelled-out "pull request"/"merge request") that would sharpen triggering.

DimensionReasoningScore

Specificity

Enumerates several specific actions ("Assess and address review feedback", "checking new reviews, responding to comments, rechecking after a push, or following up on approvals and change requests") with concrete platform names (GitHub PRs, GitLab MRs). Not 5 because the core capability verbs ("assess", "address") are broad and lack tool-level specifics; not 3 because the description covers the full review-response lifecycle across three named venues rather than just 1-2 actions.

4 / 5

Completeness

Explicitly answers both: the "what" ("Assess and address review feedback on GitHub PRs, GitLab MRs, or in conversation") and the "when" ("Use when checking new reviews, responding to comments, rechecking after a push, or following up on approvals and change requests") with concrete trigger phrases, matching the top anchor pattern exactly. Third-person/infinitive voice throughout, so no voice penalty applies.

5 / 5

Trigger Term Quality

Includes natural user phrases like "checking new reviews", "responding to comments", "rechecking after a push", "approvals", and "change requests" alongside "GitHub PRs" and "GitLab MRs". Not 5 because common synonyms and expansions are missing ("pull request"/"merge request" spelled out, "code review"); not 3 because multiple natural trigger phrases users would actually say are present.

4 / 5

Distinctiveness Conflict Risk

Receiving-side triggers ("rechecking after a push", "following up on approvals and change requests") are unambiguous author-side activities, giving the skill a clear niche. Not 5 because the description never explicitly bounds the receiving side (e.g., "on your own PRs"), leaving minor overlap risk with giving-review/code-review skills; well above anchor 3's generic overlap.

4 / 5

Total

17

/

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

Jamie-BitFlight/claude_skills

Path

.agents/skills/receiving-pr-reviews/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.