sdd-apply
Implement SDD tasks from specs and design. Trigger: orchestrator launches apply for one or more change tasks.
47
51%
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 ./internal/assets/skills/sdd-apply/SKILL.mdQuality
Discovery
25%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 relies heavily on internal jargon ('SDD', 'orchestrator', 'change tasks') without explaining what these terms mean or what concrete actions the skill performs. It appears designed for a multi-skill orchestration system but fails to describe capabilities in concrete, understandable terms. The trigger condition is system-internal rather than based on natural user language.
Suggestions
Replace jargon with concrete actions: instead of 'implement SDD tasks', list specific operations like 'modify source files, add functions, update interfaces based on design specifications'.
Add natural trigger terms users would actually say, such as 'implement changes', 'apply design', 'code modifications', 'update source code'.
Expand the 'what' section to enumerate 2-3 specific capabilities so Claude can distinguish this skill from other development-related skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague language like 'implement SDD tasks from specs and design' without listing any concrete actions. 'SDD tasks' is undefined jargon, and there are no specific capabilities enumerated. | 1 / 3 |
Completeness | It attempts to answer both 'what' (implement SDD tasks) and 'when' (orchestrator launches apply for change tasks), but both are extremely vague and rely on undefined internal terminology. The 'when' clause exists but is not user-facing. | 2 / 3 |
Trigger Term Quality | The trigger terms are internal/technical jargon ('orchestrator launches apply', 'change tasks') that no user would naturally say. These are system-internal concepts, not natural language keywords. | 1 / 3 |
Distinctiveness Conflict Risk | The mention of 'SDD' and 'orchestrator launches apply' provides some specificity to a particular workflow, but 'implement tasks from specs' is generic enough to overlap with many development-related skills. | 2 / 3 |
Total | 6 / 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, highly actionable skill for a complex multi-mode implementation workflow. Its greatest strengths are the clear step sequencing with explicit gates/checkpoints and the concrete decision trees for handling different modes and edge cases. The main weakness is moderate verbosity — some sections (merge protocol, chain strategy details, workload enforcement) could potentially be extracted to referenced files to keep the main skill leaner, and there's some repetition between steps.
Suggestions
Consider extracting the detailed chain strategy rules (Step 2a) and merge protocol (Step 6) into a referenced file to reduce the main skill's token footprint.
Remove minor redundancies — e.g., 'Mark tasks complete' appears as both part of Step 4's loop and as its own Step 5, which could be consolidated.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly long (~200 lines) with some repetition (e.g., persistence instructions appear in multiple steps, the merge protocol is explained twice). However, most content is genuinely necessary for a complex multi-mode workflow. Some sections like the orchestrator gate preamble and mode explanations could be tighter, but it doesn't over-explain basic concepts. | 2 / 3 |
Actionability | The skill provides highly concrete, executable guidance: specific mem_search queries, exact markdown checkbox syntax, precise decision trees with clear branches, a complete return summary template with all fields, and specific file paths. The pseudocode-style FOR EACH TASK block and decision trees are appropriate for workflow orchestration rather than code generation. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced (Steps 1-7) with explicit validation checkpoints: Step 2a enforces a hard gate on workload decisions before any code is written, Step 2b requires reading previous progress before starting, Step 3 has a hard gate for TDD mode, and Step 6 is marked MANDATORY with a merge protocol. Feedback loops are present (blocked states, error reporting, deviation tracking). | 3 / 3 |
Progressive Disclosure | The skill references external files well (sdd-phase-common.md Sections A-D, strict-tdd.md, openspec-convention.md, config.yaml) and the strict-tdd.md module is conditionally loaded only when needed. However, no bundle files were provided to verify these references exist, and some content that could be in referenced files (like the full return summary template and the detailed chain strategy rules) is inline, making the main file longer than necessary. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Repository
- sergiodvillegas-art/gentle-ai
- Commit
3bfa934
- 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.