A strong, dense instruction-only skill: an unambiguous 7-step workflow with real validation checkpoints and a rich set of genuinely non-obvious tips and conventions. Its weaknesses are the truncated code examples with ellipsis placeholders and the absence of any file-level split, leaving the tips and examples inlined in SKILL.md.

Suggestions

Make the Conversion Examples executable by replacing the "// ... setup grid ..." and "// ... dump results ..." ellipses with the minimal real setup (grid construction options and a complete assertion), so the examples are copy-paste ready.

Move the Tips & Troubleshooting list and the conversion examples into a `references/` file (e.g., `references/conversion-examples.md`), leaving SKILL.md as a concise workflow overview with one-level-deep pointers.

The example commit message's bug line still reads "Fixed: <issue number>" while step 6 says to supply the actual issue number — make the placeholder handling consistent so the example cannot be copied verbatim with an unfilled field.

Dimension	Reasoning	Score
Conciseness	Every section carries task-specific knowledge Claude would not already know ("Always use `import * as` for cross-module imports", "wrap all lines... to a maximum of 72 characters", helper inventories in `front_end/testing/`), with no padding or explanation of known concepts. The format-spec-plus-example commit message mirrors the rubric's endorsed pattern, matching anchor 5 (lean, assumes competence).	5 / 5
Actionability	Guidance is mostly executable: exact import conventions, named helpers (`renderElementIntoDOM`, `MockCDPConnection`, `expandRecursively(10)`), file paths, and a copy-paste commit-message template. However, both conversion code examples use ellipsis placeholders ("// ... setup grid ...", "// ... dump results ..."), which the guidelines treat as pseudocode rather than executable examples, so it sits at anchor 4 rather than 5.	4 / 5
Workflow Clarity	Seven clearly numbered steps run from identification through CL upload, with explicit validation checkpoints (step 5 build/verify, step 6 cross-reference against the original test and a decision path to close the issue) and a feedback loop (inspect the log summary for "TOTAL: X SUCCESS"). This matches anchor 5 (clear sequence, explicit validation, error-recovery guidance).	5 / 5
Progressive Disclosure	Sections are well organized and cross-skill references (`devtools-imports`, `foundation-test-migration`, `devtools-verification`) are clearly signaled, but no bundle files exist and everything — the 8-item Tips & Troubleshooting list and the conversion examples — is inlined in one ~135-line file. This is good structure with minor organization gaps (anchor 4) rather than an appropriately split overview (anchor 5).	4 / 5
	Total	18 / 20 Passed

Description

73%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 tight, well-targeted trigger description that clearly states when to use the skill and is highly distinct. Its main limitation is compression: it communicates only one action and omits the concrete sub-capabilities (conversion, BUILD.gn updates, verification, CL upload) and synonym terms that would make it both more complete and more discoverable.

Suggestions

Expand the what-statement into 2-4 concrete actions, e.g., "Converts legacy TestRunner-based Chromium layout tests into modern Mocha/Chai unit or API tests, updates BUILD.gn targets, and uploads the migration CL. Use when migrating Chromium layout tests, blink web tests, or DevTools test files."

Add natural trigger synonyms users might say, such as "blink web tests", "browser tests", or "DevTools test migration", to broaden keyword coverage.

Keep the description in third person and preserve the explicit "Use when..." clause when expanding, so both what and when remain independently explicit.

Dimension	Reasoning	Score
Specificity	"migrating Chromium layout tests to DevTools unit tests or API tests" names the domain and a single concrete conversion action, but lists no sub-capabilities (e.g., rewriting assertions, updating BUILD.gn, uploading CLs). It matches anchor 3 (1-2 concrete actions, not comprehensive) and falls short of anchor 4, which expects several specific actions.	3 / 5
Completeness	It has both an explicit "Use when..." trigger and an implicit what (the migrate-tests action embedded in the same clause), matching anchor 4. Not anchor 5 because the what is never stated as separate concrete capabilities with multiple trigger phrases; not anchor 3 because the when-clause is fully explicit rather than weakly implied.	4 / 5
Trigger Term Quality	"Chromium layout tests", "DevTools unit tests", and "API tests" are the exact phrases a user needing this skill would naturally say, giving good keyword coverage. It misses common variations such as "blink web tests" or "browser tests", keeping it below the comprehensive synonym coverage of anchor 5.	4 / 5
Distinctiveness Conflict Risk	The Chromium-layout-test-to-DevTools-test migration niche is highly specific with essentially no overlap with other skills, matching anchor 5 (clear niche with distinct triggers, minimal conflict risk).	5 / 5
	Total	16 / 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/migrate-chromium-test/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.