CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

review-models-core

Reviews Chrome DevTools frontend changes in path group models-and-core (^front_end/(core|models|entrypoints|generated)/, BUILD\.gn$, \.gni$), strictly reflecting review standards, architectural invariants, and security boundaries derived from historical code reviews.

Quality

79%

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 ./.agents/skills/review-models-core/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is a tightly written rule catalog with concrete, greppable detection patterns, explicit exemptions, and clear per-rule structure. Its only weaknesses are mild: some duplicated exemption text, implicit ERROR/WARNING severity semantics, and a length that could justify moving the rule catalog to a reference file.

DimensionReasoningScore

Conciseness

The 10 rules are dense and high-signal, with nearly every sentence carrying checkable identifiers, paths, or APIs. Minor over-explanation (e.g., 'the array return type is a legacy Shadow DOM v0 artifact') and the protocol.ts / shadowRoots()[0] 'Do not flag' text duplicated verbatim across two rules keep it below 'every token earns its place'.

4 / 5

Actionability

Each 'Look for' item is a copy-paste-ready, greppable pattern ('navigator.userAgent', 'visibility = [ "*" ]', 'try { await ...invoke_*() }', 'window.btoa', manual '/ 1000 arithmetic'), paired with explicit 'Do not flag' exemptions and a citation directive ('cite the rule id in findings'). For an instruction-only review skill this is fully actionable guidance covering the common cases.

5 / 5

Workflow Clarity

The single action is unambiguous: match the diff against the rules for the path group and cite rule ids in findings, with a stated provenance bar ('recurred in at least 5 CLs from 2 distinct reviewers'). It falls short of 5 only because how to act on ERROR vs WARNING severity (block vs suggest) is left implicit.

4 / 5

Progressive Disclosure

No bundle files exist, and the inline structure is well-organized: a scoping intro, one headed section per rule, and a consistent Severity/Why/Look for/Do-not-flag format that is easy to navigate. At 74 lines the rule catalog is slightly beyond ideal SKILL.md length and could be split into a reference file, which is the minor gap versus a 5.

4 / 5

Total

17

/

20

Passed

Description

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

The description nails a highly specific niche with strong trigger keywords, but it never says when to invoke the skill and describes only one generic action ('Reviews'). Adding an explicit 'Use when...' clause and naming the concrete review actions would lift it substantially.

Suggestions

Add an explicit trigger clause, e.g. 'Use when reviewing or landing Chrome DevTools frontend CLs that touch front_end/core, front_end/models, front_end/entrypoints, or front_end/generated paths, BUILD.gn, or .gni files.'

Name 1-2 concrete review actions instead of one generic verb, e.g. 'Flags module-layering violations (core/models importing ui/panels), trace handler invariant breaches, CDP error-handling mistakes, and security boundary gaps, citing rule IDs in findings.'

Include natural user phrasings such as 'CL', 'diff', or 'patch review' to broaden trigger term coverage.

DimensionReasoningScore

Specificity

The only action stated is 'Reviews Chrome DevTools frontend changes in path group models-and-core', with 'review standards, architectural invariants, and security boundaries' naming rule categories rather than concrete actions. The domain is named very precisely (path group with regexes), matching 'names domain and 1-2 concrete actions, but not comprehensive'; it is not 4 because no list of several specific review actions is given.

3 / 5

Completeness

The 'what' is explicit (reviews changes matching the path group against standards, invariants, and security boundaries), but there is no 'Use when...' clause; the 'when' is only weakly implied via the path regex, which caps completeness at 3.

3 / 5

Trigger Term Quality

Includes natural trigger terms such as 'Reviews', 'Chrome DevTools', 'frontend changes', 'code reviews', 'BUILD.gn', and '.gni', giving good keyword coverage. It is not 5 because common variations users would say, such as 'CL', 'diff', or 'patch', are missing.

4 / 5

Distinctiveness Conflict Risk

A clear niche with distinct triggers: a named project (Chrome DevTools frontend), an explicit path group with regexes, and named subsystems. Conflict risk with other skills is minimal, and even sibling path-group review skills would be disambiguated by the regex.

5 / 5

Total

15

/

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

Path

.agents/skills/review-models-core/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.