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.

Quality

47%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/sdd-apply/SKILL.md

Quality

Content

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

Description

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

Validation

100%

Warnings & errors only

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: 3 months ago

Table of Contents

Discovery Implementation Validation

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.