BD component-tests
Use when writing, changing, debugging, or reviewing Storybook-based Playwright component tests. That covers specs in packages/app/component-tests or packages/session-ui/component-tests, `*.fixture.tsx` files there or beside source (such as packages/gui-extensions/src/browser/panel.fixture.tsx), the stories they mount, and the shared harness in packages/storybook (playwright/config.ts, playwright/story.ts, .storybook/main.ts, preview.tsx, mocks). Also use when a component test is flaky, passed on retry, or fails with "Execution context was destroyed", "Failed to fetch dynamically imported module", or `#storybook-root` hidden. Covers mount args, source modules imported by URL, Vite dependency pre-bundling and reloads, cold vs warm Storybook, mobile drawers, geometry, and checks before pushing.
This skill helps debug Playwright component tests on Storybook—catches mounting issues, dynamic import failures, hidden root elements. The description covers the full stack: fixtures, stories, Storybook config, mocks.
Code quality scores 84%, process score 49%. No critical findings, no sandbox runs. In practice, it works as a reference for test structure and common pitfalls—but effectiveness depends on how well it navigates your specific codebase.
Install it if you write or fix component tests regularly. For one-off fixes it might be overkill.
That covers specs in packages/app/component-tests or packages/session-ui/component-tests, .fixture.tsx files there or beside source (such as…
As a process D 49/100 · Unfinished process — weak spots: result and completion, when it triggers, inputs and preconditions
The same skill appears in 1 more place: opencode
How to improve
- Your own cases (evals/evals.json, 4–6 real requests with expected answers): the full check would then run those instead of a model-drafted suite.
- A spec.yaml with trigger phrases and assertions — a behaviour contract for CI; `skilltest init` writes a template.
Guard findings · 0
✓ No critical or high findings
Files scanned: 1. Evidence is masked. Grey chips explain why severity was lowered.
Against the Agent Skills spec
✓ No remarks against the Agent Skills spec
Process rating: all ten parameters 49/100
- 0Result and completion. Does not say what the result is
- 0Inputs and preconditions. Does not say what the process needs to start
- 20When it triggers. No condition that starts the skill
- 30Running it twice. 11 mutating operations with no state check
- 50Failures and branches. 0 branches, has a failure section
- 60Tools and files. Uses tools (bash, web, node) that frontmatter does not declare
- 70Execution cost. Instruction body is 4505 tokens
- 100Steps. 64 steps
- 100Consistency. Name and required fields are in place
- 100Progress reporting. Reports progress
- medium Safety rules and hard prohibitions inside a skill: they belong in the system prompt, here they protect nothing
- low The response is described with custom markup (9 tags): a typed call is more reliable
Everything here is measured from the skill text rather than judged by a model, so the numbers are checkable. A parameter weighs more when it is a more common reason for the process to stall.
Quality signals
- +4Description does not say when NOT to use the skill (false activations)
- +3Description length 802: 120–800 characters recommended
- +3Output format is not stated: the model decides each time
- -2localhost URLs: will not work for another user
- +1No license
- +2Single-language instructions
- +5Description quotes 2 example trigger phrases
- +4Structure: 9 headings
- +3Step-by-step instructions: 64 items
- +4Has examples (1 code blocks)
Quality base 70; lint remarks subtract, signals add up to 100. Result: 84.