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.

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

65%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A dense, actionable frontend guidance file with concrete commands, thresholds, and a gated impact-analysis workflow. Its main weaknesses are restating widely-known engineering principles (hurting conciseness) and being a monolithic single file with no progressive disclosure into bundle references.

Suggestions

Trim or remove restatements of concepts Claude already knows (Rule of Three, DRY, SRP, 5 Whys, YAGNI, Red-Green-Refactor) and keep only the frontend-specific decision criteria and thresholds.

Add an explicit verify checkpoint to the destructive deletion workflows (e.g., re-run type-check/build after deletion before considering the change complete).

Move the detailed debugging-technique and failure-pattern catalogs into a references/ file and link to them from SKILL.md so the body stays a lean overview.

Dimension	Reasoning	Score
Conciseness	The body is dense and mostly assumes Claude's competence, but it restates well-known engineering concepts Claude already knows (Rule of Three, DRY, SRP, 5 Whys, YAGNI, Red-Green-Refactor) rather than confining itself to frontend-specific novelty, so it could be tightened.	2 / 3
Actionability	Provides concrete executable guidance — real Grep commands, TypeScript examples, numeric thresholds (300+ lines, 3+ levels, 16ms), and a workflow that reads package.json scripts — going beyond pseudocode to copy-paste-ready instruction.	3 / 3
Workflow Clarity	Sequences are clear and the Impact Analysis has an explicit 3-stage completion gate, but the destructive code-deletion workflows lack an explicit verify-after-action checkpoint, which caps workflow clarity per the destructive-operations guideline.	2 / 3
Progressive Disclosure	Well-sectioned with clear headers, but it is a ~230-line monolithic single file with no bundle references and content that could be externalized (debugging techniques, failure-pattern catalog) kept inline, so it is organized but not appropriately split.	2 / 3
	Total	9 / 12 Passed

Description

85%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it states four concrete capability areas and includes an explicit "Use when..." trigger, clearly distinguishing a frontend niche. Trigger-term coverage is the weakest point — it uses the skill's own framing rather than the full spread of phrases a user would naturally say.

Suggestions

Broaden trigger terms to match natural user phrasings, e.g. "Use when reviewing frontend code, deciding whether to extract a component, debugging a React render issue, or running frontend quality checks."

Name the concrete technologies in scope (React/TypeScript) so the trigger is more recognizable to users of those stacks.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete capability areas — "technical decision criteria, anti-patterns, debugging techniques, and quality check workflow" — matching the anchor for several specific concrete actions, not merely naming a domain.	3 / 3
Completeness	Explicitly answers both what it does and when to use it via the present "Use when making frontend technical decisions or performing quality assurance" trigger clause.	3 / 3
Trigger Term Quality	Has relevant natural terms ("frontend technical decisions", "quality assurance") but misses common user phrasings like "frontend code review" or "should I extract this component", so coverage is partial rather than comprehensive.	2 / 3
Distinctiveness Conflict Risk	Scoped specifically to frontend technical decisions and QA, a clear niche with distinct triggers unlikely to fire for non-frontend skills.	3 / 3
	Total	11 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: shinpr/claude-code-workflows
Commit: 66e3b29

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.