CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

spec

Turn a fuzzy feature request into a reviewable product spec — goals, non-goals, testable acceptance criteria with stable IDs, invariants — that later skills cite by path and ID. Use when the user says "/spec", "spec this out", "write a product spec", "turn this idea into requirements", or brings a feature request that needs a contract before planning or building.

Quality

100%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

100%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 body is a dense, directive six-step workflow where every sentence earns its place, backed by explicit validation, feedback loops, and sign-off gates, plus a checkable Definition of Done. Detail is correctly pushed one level deep into references/format.md, which exists and matches its advertised contents. This is a model example of an instruction-oriented skill body.

DimensionReasoningScore

Conciseness

Every sentence instructs ("The repo's convention wins", "'Fast' or 'intuitive' is a goal at best, never a criterion", "Zero silent inventions") and the brief rationale clauses serve enforcement, not concept explanation Claude already knows. Nothing trimmable was found, matching the lean anchor rather than the minor-trims anchor at 4.

5 / 5

Actionability

Fully actionable instruction-only guidance: concrete drafting rules ("The overview's first sentence says what the feature does for its user", "new criteria take fresh IDs, removed ones leave holes"), a runnable command ("Run `<plugin root>/scripts/prose-lint.py` on the spec file"), templates delegated to references/format.md at the exact step they are needed, and a checkable Definition of Done. Per the rubric's code-vs-instruction note, absence of code is not penalized.

5 / 5

Workflow Clarity

Six clearly sequenced steps with explicit validation (step 5: "Every goal is covered by at least one criterion… fix every finding"), a validate-fix loop enforced by the DoD ("passes prose-lint.py with no findings"), hard gates ("Then wait"; "the user signs off before anything downstream builds on it"), and a Definition of Done checklist — matching the anchor requiring explicit validation, feedback, and checklists.

5 / 5

Progressive Disclosure

The body is a well-signaled overview: a references table giving file, read-timing ("step 1, when the repo has no spec convention"), and contents, with the timing restated in the workflow ("Read `../../assets/writing.md` first"). references/format.md was verified to exist, be one level deep, and hold exactly what the table claims; the plugin-root-relative paths are explicitly defined ("`<plugin root>` is two directories above it") and resolve outside this bundle copy by design.

5 / 5

Total

20

/

20

Passed

Description

100%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 is exemplary: third-person, concrete, and complete. It names the full set of deliverables (goals, non-goals, ID'd acceptance criteria, invariants) and pairs them with an explicit Use-when clause containing the slash command and several natural user phrasings, including synonyms. It carves a distinct niche that is unlikely to fire for planning or implementation skills.

DimensionReasoningScore

Specificity

Enumerates multiple concrete deliverables — "goals, non-goals, testable acceptance criteria with stable IDs, invariants — that later skills cite by path and ID" — comprehensively covering what the skill produces. Not 4: there is no coverage gap; the artifact's full contents are named, not just the domain.

5 / 5

Completeness

Explicitly answers both questions: a clear what ("Turn a fuzzy feature request into a reviewable product spec…") and an explicit "Use when…" clause with concrete trigger phrases. Not 4: the when is fully explicit with quoted user phrasings, not merely present.

5 / 5

Trigger Term Quality

Covers the literal command ("/spec"), casual ("spec this out"), formal ("write a product spec"), a synonym ("turn this idea into requirements"), and a situational condition ("brings a feature request that needs a contract before planning or building"). This is comprehensive natural-term coverage for the domain; no file-extension vocabulary applies.

5 / 5

Distinctiveness Conflict Risk

Clear niche — a product-level spec with stable IDs that later skills cite — with the distinct "/spec" trigger and explicit positioning "before planning or building" that separates it from planning/building skills. Minimal conflict risk.

5 / 5

Total

20

/

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

korya/swd-skills

Path

skills/spec/SKILL.md

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.