component-fixtures

Use when creating or updating component fixtures for screenshot testing, or when designing UI components to be fixture-friendly. Covers fixture file structure, theming, service setup, CSS scoping, async rendering, and common pitfalls.

Quality

79%

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 ./.github/skills/component-fixtures/SKILL.md

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 highly actionable with concrete, executable patterns and honest pitfalls, but it is weakened by significant duplication between the 'adapting' and 'designing' sections and by being a monolithic single file with no progressive disclosure for a doc of this length. Consolidating the redundant sections and splitting deep-dive material into reference files would raise both scores.

Suggestions

Merge 'Adapting Existing Components for Fixtures' and 'Writing Fixture-Friendly Components' into one section — both repeat the same four practices (dependency injection, exposing domNode, disabling auto-focus, shallow CSS selectors).

Split the deeper material (component-design guidelines and 'Learnings') into a references/ file (e.g. design-guidelines.md) linked from SKILL.md so the main file stays an overview.

Add an explicit verification step to the workflow: after creating a fixture, screenshot it via mcp_component-exp_screenshot and confirm the component renders correctly (both Dark and Light variants) before finishing.

Dimension	Reasoning	Score
Conciseness	The body is mostly dense, domain-specific guidance with no padding about concepts Claude already knows, but 'Adapting Existing Components for Fixtures' and 'Writing Fixture-Friendly Components' substantially duplicate each other — DI, exposing domNode, auto-focus options, and shallow CSS each appear twice. Merging or trimming those sections would tighten it noticeably; it is not a 4 as-is due to this repeat content.	3 / 5
Actionability	Guidance is fully executable: copy-paste-ready TypeScript and CSS snippets ('export default defineThemedFixtureGroup({ path: 'myFeature/' }, {...})'), exact file paths ('src/vs/workbench/test/browser/componentFixtures/'), concrete tool names (mcp_component-exp_screenshot), an export-purpose table, and worked bad/better patterns. Specific examples cover the common cases.	5 / 5
Workflow Clarity	'Running Fixtures Locally' gives a clear numbered sequence (start server → list fixtures → screenshot), and the fixture-creation flow (file structure → basic pattern → utilities) is coherent. It falls short of 5 because there is no explicit verification checkpoint after screenshotting (e.g. 'confirm the screenshot renders correctly before finishing'), though the operations are non-destructive so the 3-cap does not apply.	4 / 5
Progressive Disclosure	There are no bundle files (references/, scripts/, assets/ are absent) and no external references at all; the entire ~340 lines live inline under good section headers. The doc is longer than a simple skill, and content that could be split out (component-design guidelines, learnings) is inline, matching 'some structure but content that should be separate is inline'.	3 / 5
	Total	15 / 20 Passed

Description

87%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 strong description: it explicitly answers both what the skill covers and when to use it, with natural trigger phrasing and a distinct, low-conflict niche. The only improvement is naming one or two more concrete actions or variations (e.g. '.fixture.ts' files) for full specificity and keyword coverage.

Dimension	Reasoning	Score
Specificity	The description names the domain ('creating or updating component fixtures for screenshot testing') and lists several concrete topics ('fixture file structure, theming, service setup, CSS scoping, async rendering, and common pitfalls'). It stops short of a 5 because it enumerates topic areas rather than a comprehensive list of concrete actions.	4 / 5
Completeness	Both 'what' and 'when' are explicit: 'Covers fixture file structure, theming, service setup, CSS scoping, async rendering, and common pitfalls' states scope, and 'Use when creating or updating component fixtures for screenshot testing, or when designing UI components to be fixture-friendly' gives concrete trigger phrases.	5 / 5
Trigger Term Quality	Natural phrases a user would say are present ('component fixtures', 'screenshot testing', 'UI components', 'fixture-friendly'). A few natural variations are missing — e.g. the '.fixture.ts' extension and the 'component explorer' tool name — so it is not a 5.	4 / 5
Distinctiveness Conflict Risk	This is a clear niche (VS Code component fixtures for screenshot testing) with distinct trigger terms; there is minimal realistic overlap with other skills' triggers.	5 / 5
	Total	18 / 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: posit-dev/positron
Path: .github/skills/component-fixtures/SKILL.md
Commit: b0258bc

Reviewed: 5 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.