CtrlK
BlogDocsLog inGet started
Tessl Logo

spec-validate

Validates a mainspec and its slices via 3-subagent consensus plus expert review, then *applies* impactful fixes directly to the spec files. No human-in-the-loop summary or approval — agent-first. Touches `specs/<feature>/.validated` as its final committed action.

57

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Critical

Do not install without reviewing

Fix and improve this skill with Tessl

tessl review fix ./skills/sdd/spec-validate/SKILL.md

The canonical home for this skill is spec-validate in tdg-ninja/context-specs-factory-ai

SKILL.md
Quality
Evals
Security

Quality

Content

68%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, well-sequenced operational skill with copy-paste commands and complete templates, weakened by noticeable internal repetition and a missing post-fix verification loop before committing batch edits. The single-file structure is well organized but keeps some material inline that would earn its keep as a one-level-deep reference.

Suggestions

Add a post-fix verification step after Phase 3d (e.g., re-read edited files, confirm the slice DAG and run-prd-test gate still hold) before the commit/push in 3f.

Deduplicate the sentinel-is-final rule (stated in the Invocation Contract, Phase 3f, and Notes) and replace the three identical Task() blocks with one example plus 'repeat identically for B and C'.

Move the impactful/nitpick example taxonomy or the validation-log template into a reference file to keep the SKILL.md overview lean.

DimensionReasoningScore

Conciseness

The body is mostly tight operational guidance with no concept-explanation padding, but it includes clear slack: the sentinel-is-the-final-commit rule is stated three times (Invocation Contract, Phase 3f, Notes), the three identical Task() blocks repeat one prompt verbatim, and the Notes section restates points already made (always-3 subagents, foreground parallel, expert-after-subagents). Not a 4 because these redundancies are noticeable rather than minor; not a 2 because there is no explanation of concepts Claude already knows.

3 / 5

Actionability

Fully executable throughout: exact bash commands for commit/sentinel ('git add specs/<feature>/', 'git commit -m "spec-validate: ..."', 'touch specs/<feature>/.validated'), a verbatim copy-paste subagent prompt template, concrete Task() invocations, a complete validation-log.md structure template, and specific discovery commands ('ls .claude/skills/ | grep expert'). Placeholders like <feature> are appropriate parameterization, not pseudocode, so the anchor-5 'copy-paste ready' bar is met.

5 / 5

Workflow Clarity

The sequence is explicit (numbered completion protocol, Phases 1-3 with 3a-3f sub-steps, consensus table, idempotency handling), but the workflow applies batch automated edits across multiple spec files and commits/pushes them with no post-fix verification step — no re-check of the edited spec, no re-validation of the slice DAG after fixes. Per the judging guidelines, missing validation in a batch/destructive operation caps workflow clarity at 3 even though sequencing is otherwise strong (which rules out scores 1-2).

3 / 5

Progressive Disclosure

The skill has no bundle files (references/, scripts/, assets/ all absent) and is a single well-sectioned document (Invocation Contract, Phases, Notes) with clear headers and no nested references, which is appropriate for a ~250-line workflow skill. It is not a 5 because some content that could live one level deep — the impactful/nitpick example taxonomy and the validation-log template — is fully inlined, and no reference files are used to keep the overview lean; not a 3 because structure is good and everything present is clearly signaled.

4 / 5

Total

15

/

20

Passed

Description

62%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A concrete, distinctive description that names specific actions and artifacts with real file paths, but it omits any 'when to use' trigger clause and lacks natural trigger variations, which limits discoverability and completeness. Adding an explicit 'Use when...' sentence and mentioning the validation-log output would raise it to the top anchors.

Suggestions

Add an explicit trigger clause, e.g. 'Use when a feature's mainspec and slices need validation before implementation, or when the dispatcher must produce the .validated sentinel.'

Mention the validation-log.md audit-trail output so the 'what' covers the full output contract.

Include natural synonyms such as 'spec validation', 'review the spec', or 'spec-check' to broaden trigger coverage.

DimensionReasoningScore

Specificity

The description lists several concrete actions with explicit artifacts ('Validates a mainspec and its slices via 3-subagent consensus plus expert review, then *applies* impactful fixes directly to the spec files', 'Touches `specs/<feature>/.validated` as its final committed action'), placing it at the several-specific-actions level with only minor coverage gaps (e.g., the validation-log.md output is not mentioned). It is not a 5 because coverage of the full output contract is incomplete, and not a 3 because far more than 1-2 actions are named with concrete paths.

4 / 5

Completeness

The 'what' is clear (validate via consensus plus expert review, apply impactful fixes, touch the sentinel), but the 'when' is entirely absent — there is no 'Use when...' clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 3. It is not a 2 because the 'what' is concrete rather than vague.

3 / 5

Trigger Term Quality

Relevant domain keywords are present ('mainspec', 'slices', 'spec files', 'consensus', 'validation'), but natural phrase variations a user might say ('validate the spec', 'review the spec', 'spec validation', file extensions) are missing and there is no 'Use when...' phrasing. It sits above generic keyword level (2) because the domain terms are the natural vocabulary of this pipeline, but below good coverage (4) because common synonyms are absent.

3 / 5

Distinctiveness Conflict Risk

The description occupies a clear niche in the spec-planning pipeline (mainspec/slice validation with a `.validated` sentinel and no-HITL fix application); its triggers ('mainspec', 'slices', '.validated') are distinct and would not plausibly fire a different skill. Anchor 4's 'minor overlap risk' does not apply — no neighboring skill vocabulary appears.

5 / 5

Total

15

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
tdg-ninja/context-specs-claude-code
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.