CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

pr-review

Authors a human-voice code review of someone else's pull request or merge request and posts it as a draft (pending) review for the user's approval — "review this PR", "do a code review on PR #N", "review this MR", "leave review comments". Also reviews the user's own branch when the request says "review my branch", "review locally", "review for myself", "just my branch", or "don't post": the review goes to a file and nothing is posted. Works on GitHub and GitLab. Finds issues by orchestrating the code-review and pr-review-toolkit plugins, drafts with no severity badges, and gates every post on the user's approval. This is the reviewer's side; to respond to feedback on a PR the user authored, use pr-comments-address.

74

Quality

93%

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

85%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 dense, rigorously engineered workflow: every step is executable, validation and recovery paths are explicit, and disclosure into the references is exemplary. The one real cost is length — the gate and print-in-full rules are restated several times and many sentences are long compounds that could be tightened without losing any rule.

Suggestions

Collapse the three restatements of the print-the-draft rule in step 5 into one directive plus one short brevity-mode carve-out; step 7's copy of the rule only needs to reference it, not restate the rationale.

Split the ~200-word step-1 public bullet into short sub-bullets (fetch order, preflight's draft-capability answer, the scratchpad-subagent rule, comment-only-on-changed-lines) so each instruction is scannable on one line.

Trim the repeated justifications for the verdict rules in step 4 (the 'Holding a PR open...' paragraph largely restates the classify-by-cost rule above it) to a single sentence.

DimensionReasoningScore

Conciseness

The body explains nothing Claude already knows — every paragraph carries novel, skill-specific policy — but it could be tightened. The print-the-draft-in-full requirement is stated three times across step 5's paragraphs ("Print the complete draft as message text", "The draft is the step 4 file, not your memory. Print the file's full content", and the brevity-mode carve-out) and again in step 7; and several sentences are very long compounds (the step-1 public bullet runs ~200 words) that could be split or trimmed without losing rules. This fits the "mostly efficient but could be tightened" anchor, not the "minor instances" of the 4 anchor.

3 / 5

Actionability

Fully executable for an instruction-orchestration skill: exact artifact paths (review/pr-<N>-draft.md, branch names with / replaced by -), exact commands (git remote get-url origin, gh auth status / glab auth status), exact dispatch parameters (subagent_type: "general-purpose", "not fork"), an explicit precedence order for platform resolution, and a hand-off to platform references that contain copy-paste-ready gh/glab commands and JSON payloads (verified in references/github.md). Edge cases branch explicitly (draft unavailable, existing pending review, silent engine, nesting depth limit).

5 / 5

Workflow Clarity

A 7-step numbered workflow with a checklist, explicit validation checkpoints (step 5 AskUserQuestion gate, step 6 verify the summary actually posted, step 7 self-check that the fenced summary visibly rendered), and feedback loops (re-present the revised draft and return to the gate; retry with the comment moved to the summary on out-of-diff rejection; amendments re-enter step 5 before any write). Every failure mode has a named recovery path, matching the top anchor including its error-recovery and checklist criteria.

5 / 5

Progressive Disclosure

The core workflow stays in SKILL.md while platform mechanics (github.md, gitlab.md), the local mode (local.md), engines (analysis.md), voice (house-style.md), and rationale (design-notes.md) are split into six real, one-level-deep reference files, each cited inline at its point of use with its purpose stated. All cited files and sections exist ("Merge and carry forward", "False-positive discipline", "What never goes in a posted review", the re-review examples), and the references themselves carry Contents sections. Structure and navigation match the top anchor.

5 / 5

Total

18

/

20

Passed

Description

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

An exemplary description: it answers what and when with quoted user phrasings, covers both modes and platforms concretely, and explicitly disambiguates from the sibling skill. No vague language, no over-claims, and no padding.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions with comprehensive coverage: "Authors a human-voice code review... and posts it as a draft (pending) review", "reviews the user's own branch... the review goes to a file and nothing is posted", "Works on GitHub and GitLab", "orchestrating the code-review and pr-review-toolkit plugins", "gates every post on the user's approval". Both modes, both platforms, the delivery mechanism, and the engine strategy are all named explicitly. It exceeds the score-4 anchor ("several specific actions; minor gaps") — there are no gaps in coverage of the skill's capabilities.

5 / 5

Completeness

What is explicit: author a human-voice review, post as a draft (pending) review gated on user approval, write to a file for local mode, GitHub and GitLab, plugin orchestration, no severity badges. When is explicit: concrete trigger phrases for both modes, plus a disambiguating pointer ("to respond to feedback on a PR the user authored, use pr-comments-address"). Both halves are answered clearly and explicitly, matching the top anchor exactly.

5 / 5

Trigger Term Quality

It quotes the exact natural phrases a user would say: "review this PR", "do a code review on PR #N", "review this MR", "leave review comments", "review my branch", "review locally", "review for myself", "just my branch", "don't post". Synonym coverage is thorough (PR / MR / merge request), covering both the public and local trigger space. This matches the comprehensive-synonyms anchor; nothing a user would naturally say is missing.

5 / 5

Distinctiveness Conflict Risk

It carves a clear niche — the reviewer's side, draft-gated, human-voice — and explicitly routes the nearest neighbor away ("This is the reviewer's side; to respond to feedback on a PR the user authored, use pr-comments-address"). The named plugins are framed as engines it orchestrates rather than competing triggers, so the residual overlap with the code-review plugin is a designed delegation, not a conflict. Distinct triggers plus explicit boundary = minimal conflict risk, matching the top anchor.

5 / 5

Total

20

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

provectus/awos-recruitment

Path

registry/skills/pr-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.