CtrlK
BlogDocsLog inGet started
Tessl Logo

code-review

Generic checklist for reviewing DevTools CLs (your own before upload, or someone else's on Gerrit). Covers test correctness (tautological/vacuous tests, cleanup, leaks), code clarity, CL hygiene, and points to the specialized skills to consult for imports, UI, testing, strings, models, and verification. Use when asked to review a CL, a diff, a patch, or to self-review before `git cl upload`.

75

Quality

94%

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

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

An exemplary checklist-style skill: token-efficient, grounded in exact commands, APIs, and real failure strings, with a clear ordered workflow and well-signaled delegation to specialized skills. The minor gaps are that verification steps are referenced rather than shown inline, and sections 3–4 carry enough detail that they could live in a reference file.

DimensionReasoningScore

Conciseness

The body is a dense checklist where every bullet carries DevTools-specific knowledge Claude would not otherwise have — exact APIs ('CSSWorkspaceBinding.removeInstance()'), exact error strings ('Attempted to wrap … which is already wrapped'), and concrete wrong-pattern examples. No section explains general programming concepts, and no bullet can be cut without losing real guidance, matching the lean/efficient anchor.

5 / 5

Actionability

Guidance is fully concrete and executable: real commands ('git diff origin/main...HEAD', the curl URL pattern for Gerrit comments with the ')]}\'' strip note), exact cleanup calls, a routing table with specific file/symbol triggers for each specialized skill, and specific E2E label examples ('Show user agent shadow DOM' vs 'User agent shadow DOM'). Per the scoring notes, absence of code blocks is not penalized for an instruction-only checklist when the guidance is this actionable.

5 / 5

Workflow Clarity

The numbered sections give a clear review sequence (gather context → consult specialized skills → test correctness → hygiene → clarity → CL hygiene → write comments) with a real checkpoint ('Read the CL description first. Then check that the diff does what the description says, and nothing else'). It does not reach anchor 5 because validation is delegated by reference ('Presubmit, lint, and format pass. See `devtools-verification`') rather than given as explicit validate-and-recover steps inline; this is a review checklist, not a destructive/batch operation, so the workflow-clarity cap of 3 does not apply.

4 / 5

Progressive Disclosure

No bundle files exist, so structure is scored on the SKILL.md itself. The routing table is well-signaled, one-level-deep delegation to specialized skills, and sections are clearly navigable. It sits below anchor 5 because the detailed test-correctness patterns in sections 3–4 (roughly half the file) are candidates for a reference file, leaving SKILL.md as a tighter hub — a minor organization gap rather than the clean split of the top anchor.

4 / 5

Total

18

/

20

Passed

Description

95%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: concrete capability list, explicit 'Use when' triggers with the exact upload command, and a tightly scoped DevTools/Gerrit niche. The only weakness is that it omits a couple of areas the body actually covers (context gathering, writing review comments), which keeps specificity at 4 rather than 5.

DimensionReasoningScore

Specificity

The description lists several concrete coverage areas — 'test correctness (tautological/vacuous tests, cleanup, leaks), code clarity, CL hygiene' — plus an explicit routing capability ('points to the specialized skills to consult for imports, UI, testing, strings, models, and verification'). It stops short of anchor 5 because body sections like context gathering and writing review comments are not mentioned, leaving minor gaps in coverage. The voice is third-person throughout the operative clauses ('Covers…', 'points to…'); the parenthetical '(your own before upload…)' is a possessive qualifier, not second-person framing, so no voice penalty is applied.

4 / 5

Completeness

Both 'what' (checklist covering test correctness, clarity, hygiene, and routing to specialized skills) and 'when' are explicit: 'Use when asked to review a CL, a diff, a patch, or to self-review before `git cl upload`.' This matches the anchor with concrete trigger phrases for both halves, so it is not the anchor below where 'when' is only weakly implied.

5 / 5

Trigger Term Quality

It includes the natural terms a DevTools contributor would actually say: 'review a CL, a diff, a patch', 'self-review', 'Gerrit', and the exact command trigger 'git cl upload'. CL/diff/patch cover the synonym space for a change, matching the comprehensive-synonyms anchor rather than the 'a few natural terms missing' anchor.

5 / 5

Distinctiveness Conflict Risk

The niche is sharply delimited by 'DevTools CLs', 'Gerrit', and 'git cl upload' — terms that no generic code-review or document skill would trigger on. Distinct triggers, minimal conflict risk, matching the clear-niche anchor.

5 / 5

Total

19

/

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
ChromeDevTools/devtools-frontend
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.