CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

ui-eng-vision-local-lit-renderer

Migrates legacy imperative DOM construction to local declarative Lit-html templates rendered inside existing containers.

Quality

70%

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-eng-vision-local-lit-renderer/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

This is a strong, highly actionable instruction skill: nearly every section carries codebase-specific rules, exact code patterns, and validation gates (screenshot parity, per-micro-commit builds, a closing audit checklist) rather than generic explanations. Its weaknesses are mild — some duplication between the audit checklist and earlier sections, a few patterns described without examples, an implicit process entry point, and a monolithic single-file layout despite depending on external docs.

Suggestions

Add short code snippets for the two patterns currently described only in prose — the async placeholder-then-render flow (Section 8) and a parameterized fragment factory returning LitTemplate (Section 9).

Deduplicate the Mental Audit checklist against Sections 3, 10, 11, and 13, or reframe it as page-cross-references (e.g., 're-check named imports, Section 3') to reclaim tokens.

Open with a 3-5 line overview stating the entry point (which files/signal starts Pass 2) and the expected end state, so the 17 sections read as an explicit sequence rather than a rule compendium.

DimensionReasoningScore

Conciseness

The ~240-line body is dense with project-specific constraints Claude cannot know (named-import policy, clang-format off boundaries, Gerrit moved-block behavior, widget() directive forms, WrapperWidget display:contents caveat) with almost no padding or explanation of known concepts. It falls short of 5 because the Mental Audit section repeats items already covered in Sections 3, 10, 11, and 13, and a few rules are stated twice (e.g., the Section 4 read-first requirement restated in Section 7), so minor trimming is possible.

4 / 5

Actionability

Most guidance is directly executable: the exact import line from '../../ui/lit/lit.js', 'render(this.template(), this.containerField as HTMLElement);', exact CSS ('flex: auto; height: 100%;'), exact bindings like '.data=${{variant: Buttons.Button.Variant.OUTLINED}}' and 'show=${!input.isTraceApp && input.isSidebarOpen ? 'both' : 'main'}', plus concrete component mappings. It stops short of 5 because some common patterns are described without any code (asynchronous render placeholders in Section 8, parameterized fragment factories in Section 9) and there is no complete worked example.

4 / 5

Workflow Clarity

The 17 numbered sections give a logical progression, and validation is explicit and repeated: zero-tolerance screenshot diffs (Section 10), build-and-test after each micro-commit (Section 16), a user-confirmation pause (Section 17), and a 7-question self-audit checklist including 'Does the code compile and do visual tests pass with 0% diff?'. It is not a 5 because the workflow's entry point is implicit (no step identifying target files or how this pass is kicked off — it assumes orchestrator context), and error-recovery beyond 'must be resolved before proceeding' is not elaborated.

4 / 5

Progressive Disclosure

The body is well structured with numbered, titled sections, and its two external references are clearly signaled one level deep with purpose and a MANDATORY flag ([ui_engineering.md](../../../docs/ui_engineering.md) and the no-imperative-dom-api.ts migration script); no bundle files exist to nest. It misses 5 because no SKILL.md-level overview or split exists — all ~240 lines, including detailed subsystem recipes (ListWidget migration paths, WrapperWidget rules, split-view guidelines) that could live in reference files, are inlined in one document.

4 / 5

Total

16

/

20

Passed

Description

53%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 precise, distinctive capability with correct third-person voice and no fluff, but it describes only one composite action and completely omits any 'when to use' trigger guidance. Adding an explicit trigger clause and a couple of natural synonyms would lift both completeness and trigger-term quality.

Suggestions

Add an explicit trigger clause, e.g. "Use when converting imperative DOM-building helper methods in DevTools views to Lit-html templates, or when the user asks to migrate UI code to Lit/declarative rendering."

Enumerate 2-3 concrete sub-actions (e.g., converting DOM-returning helpers to LitTemplate, wiring performUpdate()/render() lifecycles, embedding legacy elements in templates) to broaden capability coverage.

Include natural user-facing synonyms such as "lit-html", "web components", or "refactor rendering" alongside the current technical phrasing.

DimensionReasoningScore

Specificity

The description names the domain and a single concrete transformation — "Migrates legacy imperative DOM construction to local declarative Lit-html templates rendered inside existing containers" — which is one composite action described precisely, not the several distinct actions of the anchor above. It is far from vague, but it does not enumerate multiple capabilities, matching 'names domain and 1-2 concrete actions, but not comprehensive'.

3 / 5

Completeness

The 'what' is clearly stated (migrate imperative DOM construction to Lit-html templates rendered in existing containers), but there is no 'Use when...' clause or equivalent explicit trigger guidance anywhere in the description. Per the judging guidelines, a missing 'Use when' clause caps completeness at 3.

3 / 5

Trigger Term Quality

Relevant keywords are present ("Migrates", "declarative", "Lit-html templates", "DOM", "rendered") but the phrasing leans technical ("legacy imperative DOM construction", "local declarative", "existing containers") rather than the natural phrases a user would say. Common variations and synonyms such as "convert", "refactor", "lit-html", or "web components" are missing, matching 'some relevant keywords but missing common variations or synonyms'.

3 / 5

Distinctiveness Conflict Risk

The description carves out a clear niche (Lit-html template migration inside existing containers) that is unlikely to fire for unrelated skills. It falls short of the 5 anchor because, without any trigger clause and given sibling migration passes in the same family (imperative-to-declarative, component modernization), there is minor overlap risk with closely related skills.

4 / 5

Total

13

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 2 suspicious

Warning

Total

15

/

16

Passed

Repository

ChromeDevTools/devtools-frontend

Path

.agents/skills/ui-eng-vision-local-lit-renderer/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.