recipe-front-plan
Create frontend work plan from design document and obtain plan approval
52
41%
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-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 conveys a basic idea of the skill's purpose—creating a frontend work plan from a design document—but lacks the specificity and explicit trigger guidance needed for reliable skill selection. It would benefit from listing concrete actions involved in plan creation and adding a clear 'Use when...' clause with natural trigger terms.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to break down a design document into frontend implementation tasks, create a sprint plan, or needs approval for a frontend work plan.'
Include more natural trigger terms and variations users might say, such as 'implementation plan', 'task breakdown', 'UI development plan', 'spec', 'mockup', or 'frontend roadmap'.
List more specific concrete actions, e.g., 'Parses design documents, breaks down UI components into tasks, estimates effort, generates a structured work plan, and submits for approval.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names a domain (frontend work planning) and two actions (create plan, obtain approval), but lacks detail on 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 fairly thin, bringing it closer 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', 'spec', 'mockup', 'task breakdown', or 'sprint planning'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'frontend' + 'design document' + 'plan approval' is somewhat specific, but 'work plan' and 'design document' are broad enough to potentially overlap with general project planning or backend planning skills. | 2 / 3 |
Total | 7 / 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 skill provides a reasonable orchestration workflow for frontend planning with clear step sequencing and sub-agent invocation patterns. However, it lacks validation checkpoints between steps, concrete examples with real paths/values, and has some redundancy between the scope boundaries section and the execution process. The actionability would benefit from complete example prompts rather than templates with placeholders.
Suggestions
Add explicit validation/error handling between steps (e.g., 'If acceptance-test-generator returns no test files, notify user and halt' or 'Verify generated test files exist before proceeding to Step 3')
Provide a concrete, complete example of the Agent tool invocation JSON rather than just listing parameters with placeholder values
Remove or consolidate the 'Scope Boundaries' and 'Orchestrator Definition' sections into the execution process itself to reduce redundancy and improve conciseness
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill has some redundancy—the 'Scope Boundaries' section largely restates what the execution process already covers, and the 'Orchestrator Definition' section explains concepts that could be more tightly integrated. However, it's not excessively verbose. | 2 / 3 |
Actionability | The steps provide structured guidance with specific sub-agent types and prompt templates, but they rely on placeholder paths (e.g., '[path]', '[ui-spec path]') without concrete examples. The Agent tool invocation parameters are helpful but not fully copy-paste ready. | 2 / 3 |
Workflow Clarity | The three-step process is clearly sequenced and logically ordered, but there are no explicit validation checkpoints or error recovery steps. For instance, there's no guidance on what to do if test skeleton generation fails, or how to validate the work plan before seeking approval. | 2 / 3 |
Progressive Disclosure | The content is reasonably structured with clear sections, but it doesn't reference any external files for deeper details (e.g., sub-agent configuration, design document format expectations). The scope boundaries and orchestrator definition sections could be better organized or separated. | 2 / 3 |
Total | 8 / 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.