recipe-front-plan
Create frontend work plan from design document and obtain plan approval
50
55%
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/recipe-front-plan/SKILL.mdQuality
Discovery
32%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 is brief and identifies a specific workflow (creating a frontend work plan from a design document with approval), but it lacks explicit trigger guidance ('Use when...'), detailed capability listing, and natural keyword variations. It would be difficult for Claude to reliably distinguish this skill from other planning or frontend-related skills in a large skill library.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user has a design document or design spec and needs to break it into frontend implementation tasks or a work plan.'
Include more natural trigger terms and variations such as 'implementation plan', 'task breakdown', 'design spec', 'UI development plan', 'sprint tasks', '.md design doc'.
Expand the capability description to list specific actions, e.g., 'Parses design documents, identifies frontend components, estimates effort, generates a structured work plan, and submits it for approval.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names a domain (frontend work planning) and two actions (create plan, obtain approval), but lacks detail about what 'create frontend work plan' entails or what a 'design document' includes. | 2 / 3 |
Completeness | Describes what it does (create a frontend work plan from a design document and get approval) but has no explicit 'Use when...' clause or trigger guidance, which per the rubric caps completeness at 2, and the 'what' itself is also quite thin, bringing it to 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant terms like 'frontend', 'work plan', 'design document', and 'plan approval', but misses common variations users might say such as 'implementation plan', 'UI plan', 'design spec', 'task breakdown', or 'sprint planning'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'frontend' + 'design document' + 'work plan' + 'approval' is somewhat specific, but could overlap with general project planning or design-to-code skills without clearer scoping. | 2 / 3 |
Total | 7 / 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 strong actionability and workflow clarity. The multi-step process includes proper validation loops, explicit branching logic, and concrete subagent invocation parameters. Minor weaknesses include some verbosity in prompt construction templates and the inability to verify referenced external skills exist in the bundle.
Suggestions
Consider moving the detailed prompt construction templates in Step 3 into a referenced file to keep the main skill leaner and improve progressive disclosure.
Remove or shorten the 'Orchestrator Definition' section if the subagents-orchestration-guide already defines this identity and protocol—currently it duplicates context Claude would already have from that skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but includes some redundancy—e.g., restating orchestrator identity and execution protocol concepts that are already defined in the referenced subagents-orchestration-guide skill. The step-by-step process is reasonably tight but could be tightened in places (e.g., the detailed prompt construction templates in Step 3 are somewhat verbose). | 2 / 3 |
Actionability | The skill provides concrete, specific guidance: exact subagent_type strings, specific prompt templates with variable placeholders, exact shell commands (ls -la docs/design/*.md), specific file paths, and clear branching logic for different scenarios. This is copy-paste ready for an orchestrator agent. | 3 / 3 |
Workflow Clarity | The 5-step process is clearly sequenced with explicit validation checkpoints: Step 4 includes a review loop with re-invocation on needs_revision and escalation on rejection, Step 5 includes user approval with a change-request feedback loop. The workflow handles error recovery and branching decisions explicitly. | 3 / 3 |
Progressive Disclosure | The skill references external skills (subagents-orchestration-guide, acceptance-test-generator, work-planner, document-reviewer) but no bundle files are provided to verify these exist. The content is reasonably structured with clear sections, but the prompt construction details in Step 3 are quite detailed inline content that could potentially be separated. References are one-level deep which is good. | 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
adf2e4d
- 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.