feature-planner
A guided workflow for non-technical contributors (designers, PMs) to describe a feature idea and produce a detailed technical implementation plan for an engineer. Invoke manually with /feature-planner.
74
68%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/feature-planner/SKILL.mdQuality
Discovery
75%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 effectively communicates its purpose and target audience, with a clear manual invocation trigger that reduces ambiguity. Its main weakness is a lack of specific concrete actions beyond the high-level 'produce a detailed technical implementation plan', and it could benefit from more natural trigger terms that users might search for. The explicit slash command invocation and well-defined audience (designers, PMs) make it distinctive.
Suggestions
Add specific concrete actions the workflow performs, e.g., 'gathers requirements, identifies technical dependencies, generates architecture recommendations, and produces a structured implementation plan'.
Include additional natural trigger terms users might use, such as 'feature request', 'technical spec', 'PRD', 'product requirements', or 'spec document'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (feature planning) and the high-level action (produce a detailed technical implementation plan), but doesn't list specific concrete sub-actions like generating user stories, defining acceptance criteria, creating architecture diagrams, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (guided workflow to describe a feature idea and produce a technical implementation plan) and 'when' (invoke manually with /feature-planner, for non-technical contributors). The explicit invocation trigger satisfies the 'when' requirement. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'feature idea', 'implementation plan', 'designers', 'PMs', and the slash command '/feature-planner', but misses natural variations users might say like 'spec', 'requirements', 'feature request', 'technical spec', 'PRD'. | 2 / 3 |
Distinctiveness Conflict Risk | The description carves out a clear niche: it's specifically for non-technical contributors producing technical implementation plans, with a manual slash command trigger. This is unlikely to conflict with general coding skills or documentation skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
62%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 conversational workflow skill with clear phase separation and good sequencing. Its main weaknesses are verbosity (explaining social dynamics and design collaboration norms that Claude already understands) and a lack of concrete output examples — the plan template describes sections but doesn't show what a good implementation plan actually looks like. The skill would benefit from trimming explanatory prose and adding a concrete example of a completed plan.
Suggestions
Add a concrete example of a completed implementation plan (even abbreviated) so Claude has a clear reference for the expected output format and level of detail.
Trim the 'Important guidelines' section — directives like 'never talk down to the user' and 'designers are busy' describe social awareness Claude already has; focus on the non-obvious constraints like avoiding technical jargon in Phase 1.
Show concrete tool invocation patterns for Figma MCP, Linear MCP, and EnterPlanMode/ExitPlanMode rather than just naming them.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is well-written but verbose in places. The example dialogue snippets, while helpful, add significant length. Some guidelines (e.g., 'Never talk down to the user') explain social norms Claude already understands. The discovery phase interview topics could be more compressed. | 2 / 3 |
Actionability | The skill provides a clear conversational workflow and specific plan structure, but lacks concrete executable examples. The 'code sketches' and 'proposed types/interfaces' sections describe what the engineer's plan should contain rather than providing templates or examples of what good output looks like. References to tools (Figma MCP, Linear MCP, EnterPlanMode) are named but usage patterns aren't shown. | 2 / 3 |
Workflow Clarity | The two-phase workflow is clearly sequenced with explicit transitions (confirm understanding → research codebase → enter plan mode → create Linear issue → wrap up). There are feedback loops built in ('If the user wants to adjust or add things, loop back') and a clear fallback if Linear MCP is unavailable. The plan structure serves as a validation checklist. | 3 / 3 |
Progressive Disclosure | The content is a single monolithic file with no references to supporting documents. At ~200 lines, the plan template section and discovery interview guidance could be split into separate reference files. However, the internal structure with clear headers and phases provides reasonable organization within the single file. | 2 / 3 |
Total | 9 / 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
- coinbase/cds
- Commit
f79a780
- 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.