recipe-front-design
Execute from requirement analysis to frontend design document creation
50
38%
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/recipe-front-design/SKILL.mdQuality
Discovery
0%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description is extremely terse and vague, failing to communicate specific capabilities, natural trigger terms, or explicit usage conditions. It reads more like a high-level process step than a skill description, making it nearly impossible for Claude to reliably select this skill from a pool of alternatives.
Suggestions
Add a 'Use when...' clause with specific trigger terms like 'frontend design doc', 'UI specification', 'component design', 'screen layout', or 'design document'.
List concrete actions the skill performs, such as 'Analyzes user requirements, defines UI components, creates wireframe specifications, and generates structured frontend design documents including component hierarchy, state management, and API contracts'.
Specify the output format and scope more clearly (e.g., what kind of design document is produced, what frameworks or patterns it targets) to distinguish it from general documentation or backend design skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague language like 'requirement analysis' and 'frontend design document creation' without specifying concrete actions. It doesn't list what specific tasks are performed (e.g., wireframing, component specification, API contract definition). | 1 / 3 |
Completeness | The description only vaguely addresses 'what' (requirement analysis to design document creation) and completely lacks a 'when' clause or any explicit trigger guidance for when Claude should select this skill. | 1 / 3 |
Trigger Term Quality | The terms 'requirement analysis' and 'frontend design document creation' are somewhat technical/process-oriented and not natural phrases users would say. Users are more likely to say things like 'design doc', 'UI spec', 'frontend architecture', or 'component design'. | 1 / 3 |
Distinctiveness Conflict Risk | The description is very generic and could overlap with many skills related to documentation, requirements gathering, design systems, or general frontend development. There are no distinct triggers to differentiate it. | 1 / 3 |
Total | 4 / 12 Passed |
Implementation
77%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 with clear workflow sequencing, explicit validation checkpoints, and concrete sub-agent invocation patterns. Its main strengths are actionability and workflow clarity with proper [STOP] points and conditional logic. The primary weakness is that the content could benefit from better progressive disclosure by extracting sub-agent details into referenced files, and some invocation patterns are slightly repetitive.
Suggestions
Consider extracting sub-agent invocation specifications into a referenced file (e.g., SUBAGENTS.md) to reduce inline verbosity and improve progressive disclosure.
Consolidate the repeated subagent_type path pattern into a brief notation or table at the top to reduce redundancy across steps.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is moderately efficient but includes some redundancy in the sub-agent invocation patterns (repeating full subagent_type paths and description fields multiple times). Some sections could be tightened, but overall it doesn't over-explain concepts Claude already knows. | 2 / 3 |
Actionability | The skill provides highly concrete, executable guidance with specific subagent_type strings, exact prompt templates for different scenarios (PRD exists vs not, prototype available vs not), and clear parameter structures. Each invocation is copy-paste ready with specific field values. | 3 / 3 |
Workflow Clarity | The multi-step workflow is clearly sequenced with explicit [STOP] checkpoints for user approval at each phase, validation steps (document-reviewer, code-verifier), and conditional branching (ADR vs Design Doc, prototype available vs not). Feedback loops are present through review and verification steps before proceeding. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and steps, but it's somewhat monolithic — all sub-agent invocation details are inline rather than referencing separate documentation for each sub-agent's capabilities and parameters. For a skill of this complexity, separating sub-agent specifications into referenced files would improve navigation. | 2 / 3 |
Total | 10 / 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 |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- 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.