team-frontend-debug
Frontend debugging team using Chrome DevTools MCP. Dual-mode — feature-list testing or bug-report debugging. Triggers on "team-frontend-debug", "frontend debug".
76
71%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.codex/skills/team-frontend-debug/SKILL.mdQuality
Discovery
57%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 clear niche (frontend debugging via Chrome DevTools MCP) and mentions two operational modes, which aids distinctiveness. However, it lacks specific concrete actions, natural user-facing trigger terms beyond the explicit keywords, and a proper 'Use when...' clause that would help Claude know when to select this skill in broader contexts.
Suggestions
Add a 'Use when...' clause describing scenarios, e.g., 'Use when the user reports frontend bugs, CSS issues, JavaScript errors, page rendering problems, or needs to test UI features in the browser.'
List specific concrete actions the skill performs, e.g., 'Inspects DOM elements, analyzes network requests, checks console errors, evaluates page performance, and captures screenshots for debugging.'
Include more natural trigger terms users might say, such as 'browser issue', 'CSS not working', 'JavaScript error', 'page broken', 'UI bug', 'console log', or 'network request failing'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (frontend debugging) and mentions two modes (feature-list testing, bug-report debugging), but doesn't list specific concrete actions like inspecting DOM elements, analyzing network requests, checking console errors, etc. | 2 / 3 |
Completeness | The 'what' is partially addressed (dual-mode frontend debugging with Chrome DevTools MCP), and trigger terms are listed but there's no explicit 'Use when...' clause explaining when Claude should select this skill beyond the trigger keywords. | 2 / 3 |
Trigger Term Quality | Includes some relevant terms like 'frontend debug', 'Chrome DevTools', 'bug-report', and 'feature-list testing', but misses natural user phrases like 'CSS issue', 'JavaScript error', 'page not loading', 'console errors', 'browser debugging', or 'inspect element'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'Chrome DevTools MCP', 'frontend debugging team', and the dual-mode specification creates a clear niche that is unlikely to conflict with other skills. The specific tool (Chrome DevTools MCP) and explicit trigger terms make it quite distinct. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured orchestration skill that provides clear routing logic, concrete spawn templates, and explicit workflow sequences with validation checkpoints and error handling. The progressive disclosure is excellent with a clear overview pointing to role-specific files. The main weakness is moderate verbosity — some sections (Chrome DevTools tool table, completion action template) could potentially be moved to referenced spec files to reduce the token footprint of the main SKILL.md.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly long and includes some information that could be more compact (e.g., the full Chrome DevTools tool table, the agent coordination examples, completion action UI template). However, most content is reference-style tables and templates that serve as lookup material rather than verbose explanation. Some tightening is possible but it's not egregiously padded. | 2 / 3 |
Actionability | The skill provides concrete, copy-paste-ready templates for spawning workers, specific tool names with exact function signatures, a clear delegation lock table with explicit ALLOWED/BLOCKED verdicts, and executable patterns for agent coordination (send_message, followup_task, close_agent). The worker spawn template, iterative debug loop pattern, and completion action are all directly executable. | 3 / 3 |
Workflow Clarity | The dual-pipeline modes are clearly sequenced (TEST→ANALYZE→FIX→VERIFY and REPRODUCE→ANALYZE→FIX→VERIFY). Validation checkpoints are explicit: the delegation lock acts as a pre-execution gate, the iterative debug loop (FIX→VERIFY→re-FIX with max 3 rounds) provides feedback loops, agent health checks reconcile state, and timeout handling has a clear escalation path (STATUS_CHECK→FINALIZE→close). Error handling table covers edge cases. | 3 / 3 |
Progressive Disclosure | The SKILL.md serves as a clear router/overview with well-signaled one-level-deep references to role files (roles/coordinator/role.md, roles/tester/role.md, etc.) and spec files (specs/pipelines.md, specs/debug-tools.md). The architecture diagram shows the full structure upfront, and the role registry table provides direct links. Content is appropriately split between this overview and the referenced role/spec files. | 3 / 3 |
Total | 11 / 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 |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 10 / 11 Passed | |
- Repository
- catlog22/Claude-Code-Workflow
- Commit
227244f
- 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.