Break down a change into an implementation task checklist. Trigger: When the orchestrator launches you to create or update the task breakdown for a change.
68
60%
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/sdd-tasks/SKILL.mdQuality
Discovery
35%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 what the skill does but relies on internal system terminology ('orchestrator launches you') rather than natural user language for triggering. It lacks multiple concrete actions and explicit user-facing trigger terms, making it harder for Claude to correctly select this skill from a large pool.
Suggestions
Replace the orchestrator-centric trigger with natural user language, e.g., 'Use when the user asks to plan an implementation, break a feature into tasks, or create a development checklist.'
Add more specific concrete actions, e.g., 'Analyzes a proposed change, identifies subtasks, orders them by dependency, and produces a step-by-step implementation checklist.'
Include natural trigger terms users would say, such as 'task list', 'implementation plan', 'break into steps', 'development checklist', 'subtasks'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names a domain ('implementation task checklist') and one action ('break down a change'), but doesn't list multiple concrete actions like creating subtasks, estimating effort, identifying dependencies, etc. | 2 / 3 |
Completeness | The 'what' is present ('break down a change into an implementation task checklist') but the 'when' is defined in terms of an internal orchestrator mechanism rather than explicit user-facing triggers or scenarios. | 2 / 3 |
Trigger Term Quality | The trigger references an internal system concept ('orchestrator launches you') rather than natural user language. Users would say things like 'plan the implementation', 'create a task list', or 'break this into steps' — none of which are covered. | 1 / 3 |
Distinctiveness Conflict Risk | The concept of 'task breakdown' and 'implementation checklist' is somewhat specific, but 'break down a change' could overlap with planning, project management, or code review skills without clearer scoping. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
85%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 skill that provides clear, actionable guidance for breaking down changes into task checklists. Its strengths are the concrete examples (good vs bad tasks table), clear multi-step workflow with mode-conditional logic, and appropriate use of external references. Minor verbosity in the phase organization guidelines and some template repetition prevent a perfect conciseness score, but overall it's a strong skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some redundancy — the phase organization guidelines and task writing rules table, while useful, overlap somewhat. The format templates are helpful but could be slightly tighter. It doesn't explain concepts Claude already knows, which is good. | 2 / 3 |
Actionability | Highly actionable with concrete file paths, specific format templates, a clear table distinguishing good vs bad task examples, and explicit output format. The task writing rules table with ✅/❌ examples is particularly effective for guiding behavior. | 3 / 3 |
Workflow Clarity | Clear 5-step sequential workflow with explicit steps (Load Skills → Analyze Design → Write tasks.md → Persist Artifact → Return Summary). Each step has clear instructions, and the mandatory persistence step is called out explicitly. The mode-conditional branching (engram/openspec/hybrid/none) is well-structured with clear instructions per mode. | 3 / 3 |
Progressive Disclosure | Appropriately references shared skill files (`sdd-phase-common.md` Sections A-D, `openspec-convention.md`) without inlining their content. References are one level deep and clearly signaled. The skill itself is well-organized with headers for each step and collapsible detail where needed. | 3 / 3 |
Total | 11 / 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.
6901875
Table of Contents
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.