frontend-ai-guide
Frontend-specific technical decision criteria, anti-patterns, debugging techniques, and quality check workflow. Use when making frontend technical decisions or performing quality assurance.
67
58%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/frontend-ai-guide/SKILL.mdQuality
Discovery
67%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 provides a reasonable overview of the skill's domain and includes an explicit 'Use when' clause, which is good for completeness. However, it relies on abstract category labels rather than concrete actions, and the trigger terms are too broad to reliably distinguish this skill from other frontend or QA-related skills in a large skill library.
Suggestions
Replace abstract category labels with specific concrete actions, e.g., 'Evaluates component architecture tradeoffs, identifies common React/CSS anti-patterns, diagnoses rendering and performance issues, runs pre-merge frontend quality checklists.'
Add more natural trigger terms users would say, such as 'CSS bugs', 'component design', 'browser issues', 'UI review', 'performance optimization', 'responsive layout', or specific framework names.
Narrow the 'Use when' clause to reduce overlap with other skills, e.g., 'Use when reviewing frontend code quality, choosing between UI implementation approaches, or debugging visual/rendering issues in web applications.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (frontend) and lists some categories of actions ('technical decision criteria, anti-patterns, debugging techniques, quality check workflow'), but these are category labels rather than concrete specific actions like 'extract text' or 'fill forms'. | 2 / 3 |
Completeness | Answers both 'what' (frontend technical decision criteria, anti-patterns, debugging techniques, quality check workflow) and 'when' explicitly ('Use when making frontend technical decisions or performing quality assurance'). | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'frontend', 'debugging', 'quality assurance', and 'technical decisions', but misses many natural user terms like 'CSS', 'React', 'UI bugs', 'layout issues', 'browser compatibility', 'responsive design', etc. | 2 / 3 |
Distinctiveness Conflict Risk | 'Frontend technical decisions' is fairly broad and could overlap with general coding skills, CSS skills, framework-specific skills, or general debugging skills. The term 'quality assurance' is also quite generic and could conflict with testing-focused skills. | 2 / 3 |
Total | 9 / 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 is a moderately well-structured frontend decision guide that covers anti-patterns, debugging, and quality workflows. Its main weaknesses are verbosity in explaining concepts Claude already knows, incomplete actionability (descriptions over executable examples), and monolithic structure that would benefit from progressive disclosure via separate files. The content is useful but could be significantly tightened.
Suggestions
Trim explanations of well-known concepts (SRP, DRY, Rule of Three) to just the project-specific criteria/thresholds, removing definitions Claude already knows.
Add complete, executable code examples for key patterns like Error Boundary usage, Context API for prop drilling, and type guard implementations instead of just naming them.
Split into separate files: move debugging techniques to DEBUG.md, quality check commands to QA.md, and anti-patterns to ANTI_PATTERNS.md, with clear one-level references from the main skill.
Add explicit validation checkpoints to the quality check workflow (e.g., 'If Phase 1-3 fails, do NOT proceed to Phase 4-5; fix issues first').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains useful frontend-specific guidance but includes some unnecessary explanations Claude would already know (e.g., explaining what SRP means, what DRY principle is, basic debugging concepts like reading error messages). Some sections like the anti-patterns list could be tighter, and the Martin Fowler attribution is unnecessary context. | 2 / 3 |
Actionability | The skill provides some concrete guidance (grep commands for impact analysis, debug log format, TypeScript examples) but many sections are more descriptive than executable. The quality check workflow lists command names without full invocation syntax, and many anti-patterns describe what to avoid without concrete resolution code. The implementation examples are minimal and incomplete. | 2 / 3 |
Workflow Clarity | The quality check workflow has clear phases and the impact analysis has a 3-stage process, but validation checkpoints are mostly implicit. The debugging section has a reasonable sequence but lacks explicit feedback loops. The 'Implementation Completeness Assurance' section has good structure but the overall document lacks clear sequencing of when to apply which workflow. | 2 / 3 |
Progressive Disclosure | The content is organized with clear headers and sections, making it navigable. However, at ~200+ lines it's a monolithic document that could benefit from splitting detailed sections (debugging techniques, quality check commands, anti-patterns) into separate referenced files. No external file references are provided despite the content length warranting them. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- shinpr/claude-code-workflows
- Commit
2e719be
- 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.