tdg-personal/browser-qa
Use this skill to automate visual testing and UI interaction verification using browser automation after deploying features.
59
59%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
50%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 identifies a reasonable domain (visual testing via browser automation post-deployment) but remains at a moderate level of specificity without listing concrete actions or tools. It lacks an explicit 'Use when...' clause and misses common trigger terms users might naturally use. The description would benefit from more concrete actions and clearer trigger guidance to stand out among related skills.
Suggestions
Add an explicit 'Use when...' clause with natural trigger terms like 'visual regression', 'screenshot comparison', 'e2e test', 'UI test', 'end-to-end testing', or 'browser test'.
List specific concrete actions such as 'capture screenshots, compare UI layouts, simulate user clicks and form submissions, validate element visibility and states'.
Mention specific tools or frameworks if applicable (e.g., Playwright, Puppeteer, Selenium) to improve distinctiveness and help Claude differentiate this skill from general testing or deployment skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (visual testing, UI interaction verification, browser automation) and mentions a context (after deploying features), but doesn't list specific concrete actions like 'capture screenshots', 'compare layouts', 'click buttons', or 'validate element states'. | 2 / 3 |
Completeness | The 'what' is partially addressed (automate visual testing and UI interaction verification), and there is a 'when' hint ('after deploying features'), but it lacks an explicit 'Use when...' clause with clear trigger guidance. The when is embedded rather than explicitly structured. | 2 / 3 |
Trigger Term Quality | Includes some relevant terms like 'visual testing', 'UI interaction', and 'browser automation', but misses common user-facing variations such as 'screenshot comparison', 'end-to-end testing', 'e2e', 'Playwright', 'Selenium', 'regression testing', or 'UI tests'. | 2 / 3 |
Distinctiveness Conflict Risk | Somewhat specific to visual/UI testing with browser automation, but could overlap with general testing skills, browser automation skills, or deployment verification skills. The phrase 'after deploying features' helps narrow scope but isn't strongly distinctive. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a well-structured QA testing framework with clear phases and a useful output template, but falls short on actionability — it describes what to do rather than providing executable code for the browser automation tools it references. The workflow is logically sequenced but lacks explicit validation gates and error recovery guidance between phases. Tightening the prose and adding concrete MCP tool invocation examples would significantly improve it.
Suggestions
Add executable code examples showing actual MCP tool calls (e.g., `mChild__claude-in-chrome__navigate` or Playwright commands) instead of pseudocode numbered lists
Add explicit validation checkpoints between phases — e.g., 'If Phase 1 finds critical console errors, stop and report before proceeding to Phase 2'
Define the verdict categories formally (SHIP / SHIP WITH FIXES / BLOCK) with clear criteria for each based on issue severity
Trim the 'When to Use' section to 2-3 essential bullets and remove explanatory text like 'Uses the browser automation MCP... to interact with live pages like a real user'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some unnecessary framing ('like a real user'), the 'When to Use' section is somewhat verbose with overlapping bullet points, and some items explain things Claude would already know. Could be tightened. | 2 / 3 |
Actionability | Provides structured checklists and a clear output format, but all code blocks are pseudocode/numbered lists rather than executable commands. No actual browser automation code (Playwright/Puppeteer snippets) is provided — just descriptions of what to do. Missing concrete tool invocation examples for the MCP tools mentioned. | 2 / 3 |
Workflow Clarity | The four-phase structure is well-sequenced and logical, but there are no explicit validation checkpoints or feedback loops between phases. No guidance on what to do if a phase fails (e.g., should you stop at Phase 1 failures or continue?). The verdict categories in the output format hint at decision-making but aren't formalized as a workflow step. | 2 / 3 |
Progressive Disclosure | Content is reasonably organized with clear section headers and phases, but everything is inline in one file. The reference to '/canary-watch' is mentioned but not linked. For a skill this long covering 4 distinct phases, splitting detailed phase instructions into separate files with a concise overview would improve navigation. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents