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.
50
54%
Does it follow best practices?
Impact
—
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 structure with both 'what' and 'when' clauses, but suffers from abstract category-level language rather than concrete actions. The trigger terms are too broad and miss specific frontend technologies and common user phrasings that would help Claude accurately select this skill over others.
Suggestions
Replace abstract categories with concrete actions, e.g., 'Evaluates component architecture trade-offs, identifies CSS/JS anti-patterns, debugs rendering and layout issues, runs pre-merge frontend quality checks'.
Add more natural trigger terms users would say, such as 'CSS', 'JavaScript', 'React', 'UI bugs', 'layout issues', 'responsive design', 'browser compatibility', 'component structure'.
| 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 abstract categories 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', 'responsive design', 'browser compatibility', etc. | 2 / 3 |
Distinctiveness Conflict Risk | 'Frontend technical decisions' and 'quality assurance' are fairly broad and could overlap with general coding skills, code review skills, or testing skills. The frontend focus helps somewhat but 'technical decisions' and 'QA' are generic enough to cause conflicts. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill covers a broad range of frontend development concerns with reasonable structure via headers and tables, but suffers from being a monolithic document that tries to address too many topics at once. Actionability is moderate—some sections have concrete commands and code while others remain descriptive. The content would benefit from being split into focused sub-files with a lean overview, and from adding more executable code examples and explicit validation feedback loops.
Suggestions
Split the monolithic content into focused sub-files (e.g., ANTI_PATTERNS.md, DEBUGGING.md, QUALITY_CHECKS.md, TECHNICAL_DECISIONS.md) and make SKILL.md a concise overview with clear navigation links to each.
Add explicit feedback loops to the Quality Check Workflow (e.g., 'If build fails → fix type errors → re-run type-check before proceeding to Phase 4').
Replace descriptive anti-pattern entries with more concrete before/after code examples that Claude can directly apply when detecting issues.
Remove explanations of concepts Claude already knows (Rule of Three attribution, what SRP/DRY mean, what a PDF is equivalent explanations) to improve token efficiency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains some unnecessary explanations (e.g., explaining what Rule of Three is, attributing it to Martin Fowler, explaining basic concepts like SRP and DRY). However, much of the content is structured as actionable tables and lists rather than prose, keeping it reasonably efficient. Some sections like the anti-patterns list could be tighter. | 2 / 3 |
Actionability | The skill provides some concrete guidance (grep commands for impact analysis, debug log examples, quality check commands) but many sections are more descriptive than executable. Code examples are minimal and often pseudocode-like (e.g., the EmailInput example is just a signature with comments). The debugging section and quality check workflow are the most actionable parts. | 2 / 3 |
Workflow Clarity | The Quality Check Workflow has clear phases and commands, and the Impact Analysis has a 3-stage process with completion criteria. However, the quality check phases lack explicit validation checkpoints and feedback loops (e.g., what to do when a phase fails before proceeding). The debugging procedure is well-sequenced but the overall document presents many independent guidelines without clear sequencing between them. | 2 / 3 |
Progressive Disclosure | This is a monolithic document with no references to external files and no bundle files to support it. At 200+ lines covering anti-patterns, fallback design, Rule of Three, failure patterns, debugging, quality checks, technical decisions, and implementation completeness, this content would benefit significantly from being split into focused sub-documents with a concise overview in the main SKILL.md. | 1 / 3 |
Total | 7 / 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
68ecb4a
- 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.