sdd-verify

Validate that implementation matches specs, design, and tasks. Trigger: When the orchestrator launches you to verify a completed (or partially completed) change.

Quality

51%

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-verify/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 verification workflow skill with excellent actionability and workflow clarity. The step-by-step process with explicit validation checkpoints, severity classifications, and a detailed compliance matrix template makes it highly executable. The main weakness is the inline report template adding significant length, and some minor redundancy in explanations, though overall the content density is justified by the complexity of the task.

Suggestions

Consider moving the full report template (Step 8) to a separate reference file (e.g., `verify-report-template.md`) and linking to it, keeping only a brief summary of required sections inline.

Remove the redundant emphasis on 'static analysis is not enough' which appears in both the Purpose section and Step 6 — state it once definitively.

Dimension	Reasoning	Score
Conciseness	The skill is fairly long but most content is structural (workflow steps, templates, decision trees). Some redundancy exists — e.g., the purpose section explains 'static analysis alone is NOT enough' which is repeated in Step 6. The pseudocode tree diagrams add visual clarity but also bulk. Overall mostly efficient with some tightening possible.	2 / 3
Actionability	Highly actionable with concrete detection logic (package.json, pyproject.toml, Makefile fallbacks), specific commands to run, exact output formats to capture (exit codes, pass/fail counts), and a complete report template with table schemas. The compliance matrix logic is explicit and copy-paste ready.	3 / 3
Workflow Clarity	Excellent multi-step sequencing with clear numbered steps, explicit validation checkpoints (build must pass, tests must pass, compliance matrix cross-references test results), severity flagging (CRITICAL/WARNING/SUGGESTION), and a final verdict gate. Feedback loops are present — e.g., Step 6 cross-references Step 5b results, and the flag system clearly defines blocking vs non-blocking issues.	3 / 3
Progressive Disclosure	References to shared skills (`sdd-phase-common.md` Sections A-D, `openspec-convention.md`) are one-level deep and clearly signaled. However, the report template is very long and inline — it could be split into a separate reference file. The skill itself is quite long (~200+ lines) with the full report template embedded, making it harder to scan.	2 / 3
	Total	10 / 12 Passed

Description

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 is too vague to effectively guide skill selection. It lacks concrete actions (what specific validation steps are performed), uses internal jargon ('orchestrator launches you') instead of natural user language, and doesn't clearly differentiate itself from other verification or review skills. The second-person 'you' in the trigger clause also violates the third-person voice requirement.

Suggestions

List specific validation actions such as 'Compares code changes against specification requirements, checks design pattern adherence, verifies task acceptance criteria are met'.

Replace the orchestrator-focused trigger with natural user terms: 'Use when verifying code changes match requirements, checking implementation correctness, or reviewing completed features against design documents'.

Add distinct trigger terms users might say, such as 'verify implementation', 'check against spec', 'review completed work', 'acceptance criteria', 'design compliance'.

Dimension	Reasoning	Score
Specificity	The description uses vague language like 'validate that implementation matches specs, design, and tasks' without listing concrete actions. It doesn't specify what kind of validation (e.g., running tests, comparing code against requirements, checking design patterns).	1 / 3
Completeness	It has a vague 'what' (validate implementation matches specs) and a 'when' trigger clause, but the trigger is about an orchestrator launching it rather than explicit user-facing triggers. The 'when' is present but not useful for distinguishing from other skills.	2 / 3
Trigger Term Quality	The trigger terms are internal/technical jargon ('orchestrator launches you') rather than natural keywords a user would say. Terms like 'verify', 'validate', 'specs', 'design' are generic and don't reflect how users naturally phrase requests.	1 / 3
Distinctiveness Conflict Risk	The concept of validating implementation against specs is somewhat specific, but the vague language ('specs, design, and tasks') could overlap with testing skills, code review skills, or QA skills. The orchestrator-based trigger helps narrow it slightly.	2 / 3
	Total	6 / 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.