CtrlK
BlogDocsLog inGet started
Tessl Logo

code-review

Review code changes in dotnet/runtime for correctness, performance, and consistency with project conventions. Use when reviewing PRs or code changes.

70

Quality

85%

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-3

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 well-sequenced, highly actionable review process with explicit validation gates, error-recovery feedback loops, and a sound progressive-disclosure model that offloads detailed per-area rules to instruction files loaded on demand. Its chief weakness is length and redundancy, particularly the repeated API-approval instructions and restated verdict rules.

Suggestions

Consolidate the API-approval procedure into a single referenced step (e.g., describe detection in Step 1 and point to the blocking gate in Step 4 without re-explaining the whole procedure twice).

Tighten the Verdict Consistency Rules section, which restates severity/escalation guidance already covered in Step 5's 'Flag severity clearly' and the output-format Summary rules.

Consider extracting the large Multi-Model Review and Review Output Format blocks into a referenced file (e.g., OUTPUT-FORMAT.md) to reduce the inline token footprint while keeping the core Steps 0–5 lean.

DimensionReasoningScore

Conciseness

The body is substantive review guidance rather than basic concepts Claude already knows (it does not explain what a PR is), but it is long with notable redundancy — the API-approval gate is detailed in both Step 1 and Step 4, and the verdict-consistency rules restate the severity guidance — so it fits 'mostly efficient but could be tightened' rather than the lean score-3 anchor.

2 / 3

Actionability

It gives concrete executable commands (e.g., 'git log --oneline -20 -- <file>'), specific file paths to load, explicit severity markers, and a copy-paste-ready output template, matching the 'fully executable commands; specific examples' anchor; the absence of code is not penalized for an instruction-only skill with highly actionable guidance.

3 / 3

Workflow Clarity

The process is clearly sequenced (Steps 0–5) with explicit validation checkpoints — the API-approval step is a documented blocking gate — and feedback loops for error recovery (re-validate on failure) and timeouts (proceed after 10 minutes with available results), matching the score-3 'clear sequence with explicit validation steps; feedback loops' anchor.

3 / 3

Progressive Disclosure

No bundle directories (references/, scripts/, assets/) exist, but the 'Where the Review Rules Live' section signals clearly one-level-deep references to per-area instruction files (e.g., review-csharp.instructions.md, review-native.instructions.md) that are loaded only when the diff matches, matching the 'clear overview with well-signaled one-level-deep references; content appropriately split' anchor.

3 / 3

Total

11

/

12

Passed

Description

85%Weight 40%Scale 1-3

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 is specific, third-person, and complete with an explicit Use-when trigger, well-scoped to dotnet/runtime so it is unlikely to conflict with other skills. Its main weakness is somewhat narrow trigger-term coverage that omits common phrasings a user might naturally say.

Suggestions

Broaden the 'Use when' clause to include more natural phrasings users would say, e.g., 'Use when reviewing PRs, pull requests, diffs, or code changes, or when asked to critique or give feedback on a change.'

DimensionReasoningScore

Specificity

The description names the concrete domain ('dotnet/runtime') and lists multiple specific review dimensions ('correctness, performance, and consistency with project conventions'), matching the 'lists multiple specific concrete actions' anchor rather than the score-2 'some actions' anchor.

3 / 3

Completeness

It explicitly answers what ('Review code changes in dotnet/runtime for correctness, performance, and consistency') and when via an explicit 'Use when reviewing PRs or code changes' clause, matching the score-3 'clearly answers both what AND when' anchor and avoiding the score-2 cap for a missing Use-when clause.

3 / 3

Trigger Term Quality

It includes natural triggers ('reviewing PRs or code changes') but the coverage is narrow and misses common variations a user might say (e.g., 'diff', 'pull request', 'critique', 'feedback'), fitting the 'some relevant keywords but missing common variations' anchor rather than score 3's broad coverage.

2 / 3

Distinctiveness Conflict Risk

The tight scoping to 'dotnet/runtime' with project-convention-specific triggers gives it a clear niche unlikely to fire for unrelated review skills, matching the 'clear niche with distinct triggers' anchor rather than the score-2 overlap case.

3 / 3

Total

11

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
dotnet/runtime
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.