sdd-verify
Trigger: SDD verification phase, verify change. Execute tests and prove implementation matches specs, design, and tasks.
48
53%
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-verify/SKILL.mdQuality
Discovery
50%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 conveys a verification/testing skill within an SDD methodology context but relies on domain-specific jargon without sufficient natural language trigger terms. It partially addresses what the skill does and when to use it, but lacks an explicit 'Use when...' clause and concrete action details that would make it highly effective for skill selection.
Suggestions
Add an explicit 'Use when...' clause with natural trigger terms like 'run tests', 'verify implementation', 'check against spec', 'validate changes', 'test coverage'.
List more specific concrete actions such as 'runs unit tests, integration tests, compares implementation output against specification criteria, and generates verification reports'.
Expand the acronym 'SDD' (e.g., 'Spec-Driven Development') so users unfamiliar with the abbreviation can still trigger the skill appropriately.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It mentions some actions ('execute tests', 'prove implementation matches specs, design, and tasks') but remains fairly high-level without listing specific concrete actions like running unit tests, integration tests, checking code coverage, or comparing outputs against spec criteria. | 2 / 3 |
Completeness | The 'what' is partially addressed ('execute tests and prove implementation matches specs, design, and tasks') and the 'when' is implied via 'Trigger: SDD verification phase, verify change' but there is no explicit 'Use when...' clause with clear trigger guidance. Per rubric guidelines, missing explicit trigger guidance caps completeness at 2. | 2 / 3 |
Trigger Term Quality | Includes some relevant terms like 'SDD verification', 'verify change', 'tests', 'specs', and 'design', but these are somewhat jargon-heavy ('SDD verification phase') and miss common natural language variations a user might say like 'run tests', 'check implementation', 'validate code', or 'test my changes'. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'SDD verification phase' provides some distinctiveness within a specific methodology, but terms like 'execute tests' and 'verify change' are generic enough to overlap with general testing or CI/CD skills. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
57%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-organized orchestration/verification skill with good progressive disclosure and a clear decision gate table. However, it lacks concrete executable examples (no actual test commands, no sample report snippets) and misses explicit validation checkpoints within its multi-step workflow, making it more of a procedural outline than a fully actionable guide.
Suggestions
Add concrete command examples for step 7 (e.g., `npm test`, `pytest`, `tsc --noEmit`) or show how to discover the project's test command from package.json/Makefile.
Include a brief example snippet of the compliance matrix or verification report output so the executor knows the exact format expected.
Add explicit validation checkpoints in the execution steps — e.g., after step 2 (verify artifacts were retrieved successfully) and after step 7 (check exit codes before proceeding to matrix construction).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably efficient and avoids explaining basic concepts, but the orchestrator gate preamble and some of the decision gate table entries could be tightened. The activation contract section is somewhat redundant with the description. | 2 / 3 |
Actionability | The execution steps provide a clear sequence but remain abstract — no concrete commands, code snippets, or executable examples are given. Steps like 'Run test, build/type-check, and coverage commands when available' lack specificity about how to discover or invoke those commands. | 2 / 3 |
Workflow Clarity | The 9-step execution sequence is clearly ordered and the decision gates table is helpful, but there are no explicit validation checkpoints or feedback loops within the workflow. For a verification skill involving test execution and compliance checking, the absence of error recovery steps (e.g., what to do if artifact retrieval fails) caps this at 2. | 2 / 3 |
Progressive Disclosure | The skill is well-structured as an overview with clear, one-level-deep references to report-format.md, strict-tdd-verify.md, and the shared phase-common file. Navigation is well-signaled with relative paths and conditional loading instructions. | 3 / 3 |
Total | 9 / 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.