spring-planning
Create structured implementation plan in docs/plans/
39
36%
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/spring-planning/SKILL.mdQuality
Discovery
17%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 too terse and lacks critical information. It identifies a single action (creating an implementation plan) and a target directory, but fails to explain what the plan includes, when it should be used, or provide natural trigger terms that users would employ. It needs significant expansion to be useful for skill selection among many options.
Suggestions
Add a 'Use when...' clause with trigger terms like 'plan', 'implementation plan', 'project plan', 'roadmap', 'task breakdown', 'break down a feature'.
List specific concrete actions the skill performs, e.g., 'Breaks down features into phases, defines tasks with dependencies, estimates effort, and outputs a structured markdown plan in docs/plans/'.
Include natural keyword variations users might say, such as 'planning', 'project breakdown', 'step-by-step plan', 'design plan', or 'sprint plan'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names a specific action ('create structured implementation plan') and a specific location ('docs/plans/'), but does not list multiple concrete actions or elaborate on what the plan contains or how it's structured. | 2 / 3 |
Completeness | Provides a minimal 'what' (create a plan) but completely lacks a 'when' clause or any explicit trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also quite thin, warranting a 1. | 1 / 3 |
Trigger Term Quality | Contains 'implementation plan' as a keyword, but misses many natural variations users might say such as 'project plan', 'roadmap', 'task breakdown', 'planning', 'architecture plan', or 'design doc'. The term 'docs/plans/' is a file path, not a natural trigger term. | 1 / 3 |
Distinctiveness Conflict Risk | The mention of 'docs/plans/' directory adds some specificity, but 'structured implementation plan' is broad enough to overlap with general planning, documentation, or project management skills. | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
55%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides excellent actionable guidance with a well-sequenced workflow including validation checkpoints and conditional logic. However, it is severely bloated — the same testing requirements are repeated 5+ times across different sections, and the massive plan template dominates the file when it should be extracted to a separate reference. The monolithic structure makes it hard to navigate and wastes significant token budget on redundancy.
Suggestions
Extract the plan markdown template into a separate file (e.g., PLAN_TEMPLATE.md) and reference it from the main skill, reducing the SKILL.md to workflow instructions only.
Consolidate the testing requirements into a single authoritative section instead of repeating them in Development Approach, Testing Strategy, task structure guidelines comment, execution enforcement, and individual task descriptions.
Remove the lengthy HTML comment block showing example task structure — the Task 1 template already demonstrates the format, making the comment redundant.
Trim explanatory phrases like 'do not overwhelm with multiple questions' which appear both inline in step 1 and again in key principles — state once in principles only.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~250+ lines. It includes extensive template boilerplate, repeated emphasis on testing rules (stated in Development Approach, Testing Strategy, task structure guidelines, execution enforcement, and individual task templates), and lengthy HTML comments as inline documentation. Many sections restate the same principles (e.g., 'tests must pass before next task' appears 5+ times). The plan template itself is enormous and could be a separate reference file. | 1 / 3 |
Actionability | The skill provides highly concrete, actionable guidance: specific file naming conventions (yyyymmdd-<task-name>.md), exact markdown template structure, specific tool calls (AskUserQuestion with JSON format, mcp__ide__getDiagnostics), concrete examples of task structure with file paths, and clear commit message formats. The workflow is copy-paste ready. | 3 / 3 |
Workflow Clarity | The multi-step process is clearly sequenced (Step 0 → Step 1 → Step 1.5 → Step 2 → Step 2.1 → Step 3) with explicit validation checkpoints (tests must pass before next task, verify acceptance criteria), feedback loops (if tests fail → fix → retry), conditional branching (skip step 1.5 if obvious, skip step 2.1 if not JPA), and clear execution enforcement rules. | 3 / 3 |
Progressive Disclosure | The entire skill is a monolithic wall of text with no references to supporting files. The massive plan template (which is the bulk of the content) should be in a separate template file. The inline HTML comment example block is lengthy. There are no bundle files to offload content to, but the skill doesn't even attempt to structure itself with references — everything is inline in one enormous document. | 1 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- Amplicode/spring-skills
- Commit
1dd96ad
- 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.