add-task
creates draft task file in .specs/tasks/draft/ with original user intent
51
40%
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 ./plugins/sdd/skills/add-task/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.
The description is too terse and internally focused, relying on project-specific path conventions rather than natural language that would help Claude select this skill appropriately. It lacks a 'Use when...' clause, provides minimal detail about what the task file contains or why it's created, and uses no natural trigger terms a user might employ.
Suggestions
Add a 'Use when...' clause with natural trigger terms like 'create a task', 'draft a spec', 'capture requirements', 'plan work', or 'write up a task'.
Expand the 'what' to describe what the draft task file contains and its purpose, e.g., 'Creates a structured task specification capturing user requirements, acceptance criteria, and scope in .specs/tasks/draft/'.
Include natural language variations users might say, such as 'new task', 'spec file', 'task breakdown', or 'write a task description'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names a specific action ('creates draft task file') and a specific location ('.specs/tasks/draft/'), but only describes one action and the phrase 'with original user intent' is vague about what that entails. | 2 / 3 |
Completeness | It partially answers 'what' (creates a draft task file) but has no 'Use when...' clause or equivalent trigger guidance, and the 'what' itself is underspecified. Per rubric guidelines, missing 'Use when' caps completeness at 2, and the weak 'what' brings it to 1. | 1 / 3 |
Trigger Term Quality | The description lacks natural keywords a user would say. Terms like 'draft task file' and '.specs/tasks/draft/' are internal/structural jargon, not phrases a user would naturally use when requesting this functionality. | 1 / 3 |
Distinctiveness Conflict Risk | The specific file path '.specs/tasks/draft/' provides some distinctiveness, but 'task file' and 'user intent' are broad enough that it could overlap with other task management or planning skills. | 2 / 3 |
Total | 6 / 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.
The skill is highly actionable with a clear workflow and concrete templates, but is excessively verbose for the simplicity of the task. Much of the content explains things Claude already knows (how to classify bugs vs features, how to hyphenate strings, what CI means). The inline examples are helpful but three full examples plus a type table and success checklist make this much longer than necessary.
Suggestions
Cut the type classification table — Claude already knows the difference between a bug, feature, refactor, etc. A single line like 'Classify as feature/bug/refactor/test/docs/chore/ci based on intent' suffices.
Reduce examples from three to one, and trim the file naming explanation to just the pattern `<short-name>.<type>.md` with one example.
Remove the 'Analyze Input' step's clarification sub-bullets and the success criteria checklist — these restate what's already covered in the instructions and constraints.
Consider extracting the directory structure explanation into the referenced shell script's comments rather than documenting it inline.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Significantly verbose for what is essentially 'create a markdown file with a specific template in a specific directory.' The directory structure explanation, type classification table, file naming rules, success criteria checklist, and multiple examples all over-explain a straightforward task. Claude doesn't need to be told what a bug vs feature is, or how to lowercase and hyphenate strings. | 1 / 3 |
Actionability | Provides fully concrete guidance: exact bash command to run, exact markdown template to write, exact file naming convention with examples, exact output format. The task file template and naming pattern are copy-paste ready. | 3 / 3 |
Workflow Clarity | Clear 5-step sequence (ensure directories → analyze input → structure task → generate filename → create file) with a uniqueness verification step before file creation. The constraints section acts as guardrails, and the success criteria serve as a validation checklist. For a non-destructive file creation task, this level of workflow clarity is appropriate. | 3 / 3 |
Progressive Disclosure | Content is monolithic — everything is inline in one long file. The type classification table, multiple examples, and detailed naming rules could be split into referenced files. However, there are no deeply nested references, and the structure within the file (numbered steps, sections) is reasonable. | 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
- NeoLabHQ/context-engineering-kit
- Commit
dedca19
- 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.