jbvc/plan-writing
Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
72
72%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
67%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 has good structure with an explicit 'Use when' clause, which is its strongest aspect. However, it suffers from somewhat abstract capability language and overly broad trigger conditions ('any multi-step work') that could cause conflicts with other skills. The trigger terms could be more natural and varied to better match how users actually phrase planning-related requests.
Suggestions
Add more natural trigger terms users would say, such as 'plan', 'break down this task', 'steps', 'checklist', 'todo', or 'project plan'.
Narrow the 'when' clause to reduce conflict risk — 'any multi-step work' is too broad; specify the types of planning scenarios more precisely (e.g., 'Use when the user asks to plan, break down, or organize implementation tasks for features, refactors, or complex changes').
Make capabilities more concrete by listing specific actions like 'creates ordered task lists, identifies blocking dependencies between steps, and defines verification criteria for each task'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (task planning) and some actions (breakdowns, dependencies, verification criteria), but these are somewhat abstract rather than concrete actions like 'create task lists', 'identify blocking dependencies', or 'generate acceptance criteria'. | 2 / 3 |
Completeness | Clearly answers both what ('Structured task planning with clear breakdowns, dependencies, and verification criteria') and when ('Use when implementing features, refactoring, or any multi-step work') with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'implementing features', 'refactoring', and 'multi-step work', but misses many natural user phrases like 'plan', 'break down', 'todo list', 'steps', 'checklist', 'project plan', or 'task list'. | 2 / 3 |
Distinctiveness Conflict Risk | The phrase 'any multi-step work' is quite broad and could overlap with many other skills that involve planning or structured approaches. 'Implementing features' and 'refactoring' are also common triggers that other coding-related skills might match on. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a reasonably well-structured planning skill that provides good concrete examples of specific vs vague tasks and a flexible plan template. Its main weaknesses are some redundancy across principles (multiple sections making the same 'be specific' point), references to project-specific scripts without context, and a lack of explicit workflow for the plan-creation process itself. The progressive disclosure and organization are strong for a self-contained skill.
Suggestions
Add an explicit step-by-step workflow for creating a plan (e.g., 1. Assess task type, 2. Identify affected files, 3. Write tasks with verification, 4. Review plan length < 10 tasks) with a validation checkpoint before starting execution.
Remove or contextualize the 'Scripts Are Project-Specific' section—the referenced scripts (ux_audit.py, accessibility_checker.py) appear to be from a specific project setup and will confuse Claude in other contexts.
Consolidate the overlapping principles (Principles 1, 2, and 5 all emphasize specificity and brevity) to reduce redundancy and improve token efficiency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some redundancy—the tables contrasting wrong vs right approaches repeat the same point (be specific) multiple times. The 'Scripts Are Project-Specific' section references specific scripts (ux_audit.py, accessibility_checker.py) that seem project-specific rather than universally applicable, adding noise. Some principles overlap. | 2 / 3 |
Actionability | The skill provides good concrete examples of what specific tasks look like (e.g., 'Run `npx create-next-app`', 'curl localhost:3000/api/users returns 200') and includes a flexible plan template. However, it's more of a meta-guide about how to write plans rather than executable steps—there's no concrete workflow for actually creating a plan file, and the script references (ux_audit.py, etc.) are mentioned without explanation of where they come from. | 2 / 3 |
Workflow Clarity | The skill describes planning principles and provides a plan structure template, but the actual workflow for creating a plan is implicit rather than explicitly sequenced. There are no validation checkpoints for the plan-writing process itself—e.g., no step to verify the plan meets the stated criteria before proceeding with execution. | 2 / 3 |
Progressive Disclosure | For a skill of this nature (a planning methodology), the content is well-organized with clear sections, good use of tables for quick reference, and appropriate length. It doesn't need external file references and the structure flows logically from principles to template to best practices to when-to-use. | 3 / 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 |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents