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.

56

Quality

71%

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
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.

The content is a highly actionable, correctly sequenced orchestration protocol with exact prompts, commands, and output templates. Its weaknesses are the missing verification loop around the destructive apply-and-commit step, and noticeable duplication (Notes section, triple Task blocks, repeated completion protocol) that inflates token cost without adding information.

Suggestions

Add a post-edit verification step before committing — e.g., re-read each edited section or review `git diff` and confirm unrelated content is preserved — since destructive batch fix application without verification caps workflow clarity at 3.

Cut duplication: drop or merge the Notes section into the phases it restates, collapse the three identical Task() blocks into a single example plus a 'spawn 3 with identical prompts' instruction, and keep the completion protocol or Phase 3f, not both.

Make the expert-invocation step concrete — specify the actual tool call for invoking an `expert-*` skill rather than the vague `skill: "expert-*"` notation.

DimensionReasoningScore

Conciseness

The body is mostly operational detail Claude could not infer (dispatcher contract, consensus thresholds, sentinel protocol), but there is real tightening opportunity: the Notes section restates phase content ('Always 3 subagents', 'Model: opus', 'Consensus = confidence'), the completion protocol in the Invocation Contract duplicates Phase 3f's bash block, and the three near-identical Task() blocks repeat one instruction. This fits anchor 3 (mostly efficient, some unnecessary explanation or could be tightened) rather than anchor 4's 'minor instances'.

3 / 5

Actionability

Guidance is fully executable throughout: the verbatim subagent validation prompt, exact bash for commit/push/touch of the sentinel, a copy-paste validation-log.md template, concrete file paths, and the exact discovery command `ls .claude/skills/ | grep expert`. Placeholders like <feature> and [path] have explicit insertion instructions, matching the 5 anchor's copy-paste-ready coverage of common cases.

5 / 5

Workflow Clarity

The sequence is clearly ordered (numbered completion protocol, Phases 1-3 with subsections 3a-3f, idempotency and crash-mid-write handling) and findings are gated by the consensus filter. However, the destructive batch application — auto-editing spec files, committing, and pushing with no HITL — has no verification of the applied edits (no diff review, re-read, or re-validation before the sentinel), and the rubric explicitly caps destructive/batch workflows lacking validation/verification at 3.

3 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are all absent) and the skill is well-sectioned (Invocation Contract, Phases 1-3, Notes) with everything the protocol needs inline at one level; nothing is buried or nested. It sits at anchor 4 rather than 5 because at ~250 lines there are minor organization gaps (redundant Notes/completion-protocol duplication) and the 5 anchor's cleanly split, well-signaled reference structure is not demonstrated.

4 / 5

Total

15

/

20

Passed

Description

58%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.

The description communicates a concrete, niche capability with specific actions and artifacts, all in third-person voice. Its main weaknesses are the complete absence of explicit 'when to use' trigger guidance and reliance on internal pipeline jargon over natural trigger terms, which together cap completeness and trigger-term quality at 3.

Suggestions

Add an explicit trigger clause, e.g. 'Use when a feature's spec planning is complete and the specs need validation before implementation, or when invoked as /spec-validate <feature> by the dispatcher', to lift completeness above the 3 cap.

Include natural trigger phrases a user or dispatcher would actually say — 'validate the spec', 'spec review', 'check the slices' — alongside the internal jargon (mainspec, sentinel) to improve trigger-term coverage.

Mention the validation-log.md audit-trail output to round out the action coverage toward the top specificity anchor.

DimensionReasoningScore

Specificity

The description lists several concrete actions — "Validates a mainspec and its slices via 3-subagent consensus plus expert review", "applies impactful fixes directly to the spec files", "Touches specs/<feature>/.validated as its final committed action" — with named artifacts and paths. It falls short of the 5 anchor because coverage is not comprehensive (the validation-log.md output and the commit/push behavior are unstated), but clearly exceeds the 3 anchor's '1-2 concrete actions'.

4 / 5

Completeness

The 'what' is clearly stated (validate specs via consensus plus expert review, apply impactful fixes, write the .validated sentinel), but there is no 'Use when...' clause or equivalent explicit trigger guidance — 'agent-first' and 'No human-in-the-loop' describe behavior, not when to invoke the skill. Per the judging guidelines, a missing 'when' caps completeness at 3.

3 / 5

Trigger Term Quality

Relevant keywords exist ("validates", "spec", "mainspec", "slices", "fixes"), but the phrasing leans on internal protocol jargon ("mainspec", "agent-first", the .validated sentinel) rather than natural phrases a user would say, and common variations like "spec review", "check the spec", or "spec audit" are absent. It matches anchor 3 (some relevant keywords, missing variations/synonyms) better than anchor 4's 'good keyword coverage with only a few natural terms missing'.

3 / 5

Distinctiveness Conflict Risk

The named artifacts (mainspec, slices, .validated sentinel) establish a clear niche in a spec-planning pipeline that is mostly distinct from generic skills. It does not reach the 5 anchor's 'distinct triggers' because no explicit trigger phrases are given and terms like 'spec', 'review', and 'fixes' carry minor overlap risk with closely related spec-layer or review skills.

4 / 5

Total

14

/

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-factory-ai
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.