CtrlK
BlogDocsLog inGet started
Tessl Logo

pr-review

End-to-end PR reviewer for dotnet/maui. Orchestrates 3 phases — Pre-Flight, Try-Fix, Report. Gate runs separately before this skill. Use when asked to 'review PR #XXXXX', 'work on PR #XXXXX', or 'fix issue #XXXXX'.

66

Quality

78%

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 ./.github/skills/pr-review/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

70%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 orchestration document: the phase sequence, gates, checklists, and error-recovery paths are exemplary, and commands/paths are concrete. Its weaknesses are repetition-heavy emphasis padding the token budget, and a 277-line body that inlines the full Phase 2 playbook instead of pushing it to a referenced file the way Phases 1 and 3 do.

Suggestions

Move the detailed Phase 2 playbook (prompt template, cross-pollination round, selection criteria, common mistakes) into a pr-try-fix.md phase doc like pr-preflight.md/pr-report.md, leaving only the mandate, model list, and time budget in SKILL.md.

Consolidate the repeated 'Phase 2 is mandatory / never skip / no exceptions' statements into one clearly flagged rule; the sync-mode rule also appears three times (Critical Rules, mandatory paragraph, Common Mistakes).

Trim the ~90-minute budget paragraph to its actionable rules (run each model once, write content.md after each attempt, stop at 90 minutes or when progress stalls) and drop the restated rationale.

DimensionReasoningScore

Conciseness

The body is mostly dense operational detail with no basic-concept padding, but it could be tightened: the Phase 2 mandate is repeated at least four times ("THIS PHASE IS MANDATORY. YOU MUST NEVER SKIP IT. NO EXCEPTIONS", the Critical Rules bullet, the checklist, and Common Mistakes), and the ~90-minute budget paragraph re-states the same stop-early rule three ways. This matches 'mostly efficient but includes some unnecessary explanation or could be tightened'. Not 4 because the repetition and the long time-budget block are more than minor instances.

3 / 5

Actionability

Guidance is largely copy-paste ready: exact commands ('pwsh .github/scripts/EstablishBrokenBaseline.ps1 -Restore'), an exact output-directory tree, a filled-in try-fix prompt template, a content.md template, and an error-recovery table with fixes. It misses 5 because key steps remain placeholders — the prompt template's '{bug description}', '{test command}', and 'invoke try-fix skill via a general-purpose task agent with that model' never show how to select the model or assemble the inputs — so the common case is not fully self-contained.

4 / 5

Workflow Clarity

The three phases are explicitly sequenced with per-phase gates ('Gate: Phases 1-2 must be complete'), validation checkpoints (checklist items, mandatory per-attempt content.md updates, test pass/fail required before fix selection), feedback loops (retry limits in the Environment Blockers table, cleanup-and-retry in Common Errors), and a Quick Reference table. This matches the top anchor 'clear sequence with explicit validation steps; feedback loops for error recovery; checklists'. Despite touching git state, validation and recovery steps are present, so the destructive-operation cap does not apply.

5 / 5

Progressive Disclosure

Phase instruction docs are clearly signaled one level deep ('Read and follow `.github/pr-review/pr-preflight.md`'), but no bundle files exist (no references/, scripts/, assets/) while the body references paths like `.github/skills/try-fix/SKILL.md` and `.github/scripts/EstablishBrokenBaseline.ps1` that are not part of this skill's bundle. Meanwhile the very detailed Phase 2 material (~120 lines of prompt templates, rounds, and selection rules) is inlined in SKILL.md where it belongs in a separate phase file, matching 'content that should be separate is inline'. Not 2 because overall structure and navigation (headers, Quick Reference) are genuinely good.

3 / 5

Total

15

/

20

Passed

Description

87%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: third-person, domain-scoped, with a clear what and an explicit 'Use when' clause containing concrete natural trigger phrases. The only gap is that the three phases are named but not characterized, which slightly limits specificity and synonym coverage.

Suggestions

Briefly characterize each phase's action (e.g., 'code-review the diff, explore alternative fixes with 2 models, write the recommendation') instead of only naming them.

Add common trigger variations such as 'PR review', 'review pull request #XXXXX', or 'work on PR' so the natural-phrasing coverage is comprehensive.

DimensionReasoningScore

Specificity

The description names the domain ('End-to-end PR reviewer for dotnet/maui') and several concrete actions ('Orchestrates 3 phases — Pre-Flight, Try-Fix, Report', 'Gate runs separately before this skill'), so it sits at 'several specific actions; minor gaps'. It falls short of 5 because it never says what the phases actually do (code review, fix exploration, recommendation) — the reader only gets phase names.

4 / 5

Completeness

It explicitly answers both: what ('End-to-end PR reviewer... Orchestrates 3 phases — Pre-Flight, Try-Fix, Report') and when ("Use when asked to 'review PR #XXXXX'..."), with concrete trigger phrases — matching the top anchor exactly. Not below 5 because neither half is vague or merely implied.

5 / 5

Trigger Term Quality

The quoted triggers — "Use when asked to 'review PR #XXXXX', 'work on PR #XXXXX', or 'fix issue #XXXXX'" — are natural phrases a user would say, matching 'good keyword coverage; a few natural terms missing'. Not 5 because common variations like 'PR review', 'pull request', or 'look at PR' are absent.

4 / 5

Distinctiveness Conflict Risk

It carves a clear niche (dotnet/maui PR review with numbered PR triggers) that would not collide with generic code-review or git skills, matching 'clear niche with distinct triggers; minimal conflict risk'. Score 4 would require some overlap concern, which the repo-scoped, PR-number-specific triggers preclude.

5 / 5

Total

18

/

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
dotnet/maui
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.