devtools-setting-migration

Workflow for splitting an existing SettingRegistration into a SettingDescriptor (placed in the lowest layer where used: core/, models/, or ui/settings/) and SettingUIDescriptor (registered in a higher-level -meta.ts file, outside of core/ and models/).

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/devtools-setting-migration/SKILL.md

Quality

Content

63%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 delivers highly actionable, domain-specific migration guidance with concrete code, exact paths, and a validation step, but it pays for it in repetition — principles restated across sections and examples duplicating workflow code — and keeps everything, including an API reference, inline in one long file. Tightening the duplication and splitting the examples/interface reference into bundle files would lift both conciseness and progressive disclosure.

Suggestions

Consolidate the layer-placement rules so they appear once: Step 1's lowest-layer decision logic repeats the Key Principles section nearly verbatim.

Move the two full before/after examples and the Interface Reference Summary into references/ files (e.g. references/examples.md, references/interface.md) and link them from a short overview, reducing the body to the workflow plus one compact example.

Add an error-recovery loop to Step 6 (e.g., "If autoninja fails on a missing BUILD.gn entry, re-check Step 5's sources/exports and rebuild") to make the validation step a true feedback checkpoint.

Dimension	Reasoning	Score
Conciseness	The content is dense with non-obvious domain rules (layer boundaries, -meta.ts restrictions) and assumes competence rather than explaining basics, but the Key Principles section is restated in Step 1 ("NEVER place descriptors in panels/"), and both full worked examples re-print code nearly identical to the Step 2-4 snippets. Not 4 because the repetition between the principles, workflow, and examples sections is a noticeable trim opportunity.	3 / 5
Actionability	Concrete TypeScript snippets with exact file paths ("ui/settings/ConsoleSettings.ts", "core/sdk/SDKSettings.ts"), specific commands ("autoninja -C out/Default", "npm run lint"), and BUILD.gn edit instructions make this mostly copy-paste ready. Not 5 because several snippets elide details — "options: [...]" — and Example 1's main-meta.ts uses Common and i18nLazyString without importing them.	4 / 5
Workflow Clarity	A clear six-step sequence (locate → define descriptor → move UI registration → update call sites → update BUILD.gn → verify) ends with an explicit validation step (build, lint, tests), and it is not capped since verification is present. Not 5 because there is no error-recovery feedback loop (e.g., what to do when autoninja or lint fails) and no checklist for the multi-file cleanup.	4 / 5
Progressive Disclosure	The single ~290-line file is well-headered but monolithic: the Interface Reference Summary (~30 lines of API reference) and the two long before/after examples are inlined content that would sit better in separate reference files, and no bundle files (references/, scripts/, assets/) exist to offload them. Not 4 because inlining the API reference and duplicated examples in an already-long body exceeds "minor organization gaps"; not 2 because section structure and navigation within the file are clear.	3 / 5
	Total	14 / 20 Passed

Description

62%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 states a specific, well-scoped capability with precise architectural vocabulary, but it entirely lacks an explicit "when to use" trigger clause and misses the natural user phrasings ("migrate", "DevTools setting") that drive invocation. It is distinctive but incomplete as a trigger description.

Suggestions

Append an explicit trigger clause, e.g. "Use when migrating or refactoring DevTools settings registrations, or when the user mentions SettingRegistration, moduleSetting, or settings -meta.ts files."

Include natural-language synonyms alongside the technical identifiers — "migrate", "DevTools setting", "settings registration" — so the description matches how users actually phrase the request.

Briefly mention the call-site rewrite (moduleSetting -> resolve) to make the described scope match the full workflow in the body.

Dimension	Reasoning	Score
Specificity	"Workflow for splitting an existing SettingRegistration into a SettingDescriptor (placed in the lowest layer where used: core/, models/, or ui/settings/) and SettingUIDescriptor (registered in a higher-level -meta.ts file...)" names the domain and several concrete actions with precise placement rules. Not 5 because it omits part of the workflow's coverage (e.g., the moduleSetting-to-resolve call-site migration and BUILD.gn updates described in the body).	4 / 5
Completeness	The "what" is clearly and concretely stated (split a SettingRegistration into two descriptors with placement rules), but there is no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines. Not 2 because the "what" is strong and specific rather than vague.	3 / 5
Trigger Term Quality	Technical identifiers like "SettingRegistration", "SettingDescriptor", "-meta.ts", "core/", "models/" are present and match what a DevTools engineer would say, but natural phrasings users actually type — "migrate", "migration", "DevTools setting" — are missing, and there are no synonyms or variations of the key terms.	3 / 5
Distinctiveness Conflict Risk	"Splitting an existing SettingRegistration into a SettingDescriptor... and SettingUIDescriptor" occupies a clear niche (DevTools settings-layer migration) with highly specific trigger terms, making conflict with other skills minimal. Not 4 because no closely related skill would plausibly collide with these exact identifiers.	5 / 5
	Total	15 / 20 Passed

Validation

100%

Warnings & errors only

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/devtools-setting-migration/SKILL.md
Commit: de3f9ca

Reviewed: 9 days ago

Table of Contents

Discovery Implementation Validation

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.