CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

devtools-ui-widgets

Guidelines for building UI widgets using the MVP architecture in DevTools. Covers Widget lifecycle, lit-html views, and state management.

Quality

73%

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/ui-widgets/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%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 highly actionable, executable guide with complete code examples, exact signatures, and clearly sequenced refactoring and implementation workflows. Its weaknesses are redundancy (styling rules repeated four times, several overloaded bullets) and the total absence of progressive disclosure — a 385-line monolith whose worked examples and migration details belong in reference files.

Suggestions

Split content into reference files, e.g. references/example-widget.md for the full step-by-step implementation and test example, and references/legacy-migration.md for the WrapperWidget/ListWidget/TabbedPane migration details, keeping SKILL.md as a concise overview with clearly signaled one-level-deep links.

Consolidate the @scope styling guidance, which currently appears four times (Refactoring Note, refactoring step 5, Styling Strategy, and the example CSS), into a single authoritative section.

Add an explicit validation checkpoint to the refactoring workflow (e.g., step 6: "Run the widget's unit tests and verify rendered output via the view stub") so the sequence ends in a feedback loop.

DimensionReasoningScore

Conciseness

The body is dense with DevTools-specific rules and rarely explains concepts Claude already knows, but it could be tightened: the @scope styling guidance is repeated four times (the Refactoring Note, refactoring step 5, the "Styling Strategy" section, and the example CSS), and several bullets are run-on multi-clause walls of text (the WidgetOptions/render-container bullet, the ListWidget migration bullet, and the eventMixin bullet). This matches anchor 3 ("Mostly efficient but includes some unnecessary explanation or could be tightened") rather than anchor 4, since the repetition and unwieldy bullets go beyond minor trims; it is well above anchor 2's padded verbosity.

3 / 5

Actionability

Quotes: complete copy-paste-ready code for the widget file (MyExampleWidget.ts with ViewInput/ViewOutput/DEFAULT_VIEW/presenter), the parent composition example using `${widget(MyExampleWidget, {title: input.title})}`, the `static override readonly INJECT` dependency-injection pattern, and a full test file using `createViewFunctionStub`, `renderElementIntoDOM`, and `await view.nextInput`. Signatures, file paths, and helper names are exact, and the examples cover the common cases (create, compose, inject, test). This fully matches anchor 5 ("Fully executable; copy-paste ready code or commands; specific examples cover the common cases").

5 / 5

Workflow Clarity

Quotes: "Refactoring Legacy Components" provides a clearly sequenced 5-step list (Analyze Rendering Logic → Convert Base Class → State Migration → Update Usage → Scoping Styles), and the "Step-by-Step Implementation Example" runs create → compose → test. Verification guidance exists in the Testing section (assert on ViewInput via stubs), but it is not integrated as an explicit validation checkpoint within the refactoring sequence (e.g., "run the widget's tests after migration"). This matches anchor 4 ("Clear sequence with most checkpoints present; minor validation gaps") rather than anchor 5, which requires explicit validation steps and feedback loops inside the workflow. The destructive/batch cap does not apply, as this is a code-guidance skill.

4 / 5

Progressive Disclosure

There are no bundle files at all — references/, scripts/, and assets/ do not exist — so all ~385 lines live inline in SKILL.md. Section headers are clear and well-ordered (Presenter rules, View rules, Composition, Refactoring, Gotchas, Example, Testing), but content that belongs in separate reference files is inlined: the full worked implementation example, the complete test example, and the lengthy ListWidget/WrapperWidget migration details. This matches anchor 3 ("Some structure but could be better organized; content that should be separate is inline") rather than anchor 4 (which expects appropriately split content) or anchor 2 (minimal structure — the sectioning here is genuinely good).

3 / 5

Total

15

/

20

Passed

Description

61%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 clearly identifies its niche (DevTools UI widgets with MVP/lit-html) and uses good domain keywords, making it unlikely to trigger the wrong skill. Its main weakness is the absence of any explicit 'when to use' trigger clause and its action-level vagueness — it lists covered topics rather than concrete capabilities, capping both completeness and specificity.

Suggestions

Add an explicit trigger clause, e.g. "Use when creating or refactoring UI widgets, views, or panels in the DevTools front_end codebase, or when working with UI.Widget, lit-html views, or widget composition."

Enumerate concrete capabilities instead of topic labels: building widgets, refactoring legacy imperative components (VBox/Panel/HTMLElement) to MVP, composing child widgets, dependency injection via Universe, and testing with view stubs.

Include natural variation terms users would say, such as "refactor", "panel", "component", "presenter", and "front_end", to broaden trigger coverage.

DimensionReasoningScore

Specificity

Quotes: "Guidelines for building UI widgets using the MVP architecture in DevTools" and "Covers Widget lifecycle, lit-html views, and state management". It names the domain and lists several covered topics, but these are topic labels rather than concrete actions, and significant capabilities from the body (refactoring legacy widgets, widget composition, testing) are omitted. This matches anchor 3 ("Names domain and 1-2 concrete actions, but not comprehensive") and falls short of anchor 4, which requires several specific actions with only minor gaps.

3 / 5

Completeness

Quotes: "Guidelines for building UI widgets using the MVP architecture in DevTools" gives a clear 'what', but there is no "Use when..." clause or equivalent trigger guidance; the 'when' is only weakly implied by the topic itself. Per the judging guideline, a missing 'Use when...' clause caps completeness at anchor 3 ("Has a clear 'what' but 'when' is missing or only weakly implied"), below anchor 4 which requires both present.

3 / 5

Trigger Term Quality

Quotes: "UI widgets", "MVP architecture", "DevTools", "Widget lifecycle", "lit-html", "state management". These are natural terms a DevTools contributor would use, giving good keyword coverage, though common variations like "refactor", "panel", "component", or "presenter" are missing. This fits anchor 4 ("Good keyword coverage; a few natural terms missing") better than anchor 3 (single relevant keyword) or anchor 5 (comprehensive synonyms/extensions).

4 / 5

Distinctiveness Conflict Risk

Quotes: "MVP architecture in DevTools", "lit-html", "UI widgets" pin a clear niche with low conflict risk against unrelated skills. However, "state management" and "MVP architecture" are broad terms shared with generic architecture/state skills, so it sits at anchor 4 ("Mostly distinct; minor overlap risk") rather than anchor 5 ("Clear niche with distinct triggers; minimal conflict risk").

4 / 5

Total

14

/

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/ui-widgets/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.