sdd-apply
Implement tasks from the change, writing actual code following the specs and design. Trigger: When the orchestrator launches you to implement one or more tasks from a change.
56
47%
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-apply/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 vague and internally-focused to be effective for skill selection. It describes a generic code implementation role without specifying what types of code, languages, or concrete actions it performs. The trigger condition references an internal orchestrator system rather than natural user language, making it poorly suited for disambiguation among multiple skills.
Suggestions
Specify concrete actions and scope, e.g., 'Writes and modifies source code files, creates functions, classes, and modules based on task specifications' including languages or frameworks if applicable.
Replace the orchestrator-focused trigger with user-facing trigger terms, e.g., 'Use when the user asks to implement a feature, write code for a task, or build functionality based on a design spec.'
Add distinguishing details that separate this from other coding skills, such as the types of changes it handles (e.g., 'new features', 'bug fixes', 'refactors') or the workflow stage it belongs to.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague language like 'implement tasks' and 'writing actual code following the specs and design' without specifying what kind of code, what languages, what concrete actions (e.g., create files, modify functions, write tests). 'Implement tasks from the change' is abstract. | 1 / 3 |
Completeness | It attempts to answer both 'what' (implement tasks, write code) and 'when' (when the orchestrator launches you), but the 'when' clause describes an internal system trigger rather than explicit user-facing triggers. The 'what' is also very vague. | 2 / 3 |
Trigger Term Quality | The trigger terms are internal/system-oriented ('orchestrator launches you', 'tasks from a change') rather than natural keywords a user would say. No user would naturally say 'implement tasks from a change' — these are internal workflow terms, not user-facing trigger terms. | 1 / 3 |
Distinctiveness Conflict Risk | 'Writing actual code' and 'implement tasks' are extremely generic and could overlap with virtually any coding-related skill. There is nothing that carves out a distinct niche — any code implementation skill would match these same terms. | 1 / 3 |
Total | 5 / 12 Passed |
Implementation
77%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 implementation skill with excellent actionability and workflow clarity, particularly the TDD RED→GREEN→REFACTOR cycle with explicit validation at each stage. The multi-mode persistence handling (engram/openspec/hybrid/none) is thorough. The main weakness is that the skill is somewhat long with everything inline, and some sections could be more concise or split into referenced files for better progressive disclosure.
Suggestions
Consider moving the detailed TDD workflow (Step 3a) and the return summary template (Step 6) into referenced files to reduce the main skill's length and improve progressive disclosure.
Tighten the 'Detect Implementation Mode' and 'Detect test runner' sections — the ASCII tree format is visually clear but verbose; a simple priority list would convey the same information more concisely.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but has some verbosity — the ASCII tree diagrams for detection logic and the TDD cycle could be tighter. Some sections like 'What You Receive' restate what the orchestrator already provides. However, most content is necessary given the complexity of the workflow. | 2 / 3 |
Actionability | The skill provides highly concrete, actionable guidance: specific file paths, exact markdown checkbox syntax, clear detection priority orders, a complete TDD cycle with explicit steps, and a detailed return summary template with table formats. Every step tells Claude exactly what to do. | 3 / 3 |
Workflow Clarity | The multi-step workflow is clearly sequenced (Steps 1-6) with explicit validation checkpoints — TDD mode includes RED (confirm fail) → GREEN (confirm pass) → REFACTOR (confirm still pass) feedback loops. The standard workflow also has clear sequencing. Persistence is marked as MANDATORY with explicit instructions per artifact mode. | 3 / 3 |
Progressive Disclosure | The skill references external files well (sdd-phase-common.md Sections A-D, openspec-convention.md, config.yaml) and keeps them one level deep. However, the skill itself is quite long (~150+ lines) with the full TDD workflow, detection logic, and return template all inline. The TDD workflow details and the return summary template could potentially be split into referenced files to keep the main skill leaner. | 2 / 3 |
Total | 10 / 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
- Gentleman-Programming/agent-teams-lite
- Commit
6901875
- 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.