Frontend debugging team using Chrome DevTools MCP. Dual-mode — feature-list testing or bug-report debugging. Triggers on "team-frontend-debug", "frontend debug".
60
71%
Does it follow best practices?
Impact
—
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 provides some structural clarity. However, it lacks specific concrete actions, relies on command-like trigger terms rather than natural user language, and doesn't fully describe when Claude should select this skill in terms of user scenarios or intents.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Inspects DOM elements, analyzes network requests, checks console errors, evaluates CSS rendering issues'.
Expand trigger terms with natural user language like 'CSS not working', 'JavaScript error', 'page layout broken', 'browser console', 'inspect element', 'network request failing'.
Rewrite the 'Triggers on' clause as a proper 'Use when...' statement describing user scenarios, e.g., 'Use when the user reports frontend bugs, needs to test UI features across browsers, or mentions Chrome DevTools, console errors, or page rendering issues'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (frontend debugging) and mentions two modes (feature-list testing, bug-report debugging) plus the tool (Chrome DevTools MCP), 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 (frontend debugging with Chrome DevTools, dual-mode operation), and there's a 'Triggers on' clause which serves as a 'when', but the triggers are narrow command-like terms rather than natural usage scenarios. The 'when' doesn't describe situations or user intents comprehensively. | 2 / 3 |
Trigger Term Quality | Includes some relevant terms like 'frontend debug', 'bug-report', 'Chrome DevTools', but misses many natural user phrases like 'CSS issue', 'JavaScript error', 'console error', 'page not loading', 'browser debugging', 'inspect element'. The trigger terms listed ('team-frontend-debug') feel more like internal command names than natural language. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'frontend debugging', 'Chrome DevTools MCP', and the specific dual-mode approach creates a clear niche that is unlikely to conflict with other skills. It's distinctly scoped to browser-based frontend debugging via a specific tool. | 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, actionable guidance for a multi-agent frontend debugging workflow. Its strengths are excellent workflow clarity with explicit validation checkpoints, strong progressive disclosure with clear references to role-specific files, and highly actionable spawn templates and tool usage patterns. The main weakness is moderate verbosity — some sections like the full Chrome DevTools tool table and completion action UI template could be more compact without losing clarity.
| 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 material that workers/coordinator need, and there's minimal explanation of concepts Claude already knows. Some sections like the full MCP tool listing and verbose spawn templates could be tightened. | 2 / 3 |
Actionability | The skill provides highly concrete, executable guidance: exact tool names, spawn templates with specific parameters, delegation lock tables with clear ALLOWED/BLOCKED verdicts, specific CLI commands, JSON structures for session state, and precise workflow patterns. The worker spawn template and iterative debug loop pattern are copy-paste ready. | 3 / 3 |
Workflow Clarity | Multi-step processes are clearly sequenced with explicit validation checkpoints. The pipeline modes table shows clear flows (TEST → ANALYZE → FIX → VERIFY), the delegation lock provides a validation checkpoint before every tool call, the iterative debug loop has explicit feedback loops (FIX → VERIFY → re-FIX with max 3 rounds), agent health checks reconcile state, and timeout handling has a clear escalation sequence (STATUS_CHECK → FINALIZE → close). | 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 immediately shows the structure, and the role registry table provides direct links to each role's detailed instructions. | 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 | |
5ff5e86
Table of Contents
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.