CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

sdlc-define-specs

Generates or updates highly detailed, machine-readable technical specification documents in the /spec/ directory.

Quality

63%

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

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/sdlc-define-specs/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

56%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 skill body delivers a well-sequenced SDLC workflow with genuinely concrete templates, phrases, and handoff prompts, but it is significantly padded: persona-override theatrics and repeated directives inflate token cost, and the entire mandatory template is inlined rather than split into reference files. Removing duplication and moving the template plus documentation standards into references/ would materially improve both conciseness and progressive disclosure.

Suggestions

Deduplicate repeated rules (Scope Detection, Lazy Creation, ADR triple-gate, heavy-lifting, handoff routing) into single authoritative sections and remove the 'Dynamic Persona Activation [CRITICAL SYSTEM OVERRIDE]' preamble, which adds ~20 lines of no operational value.

Move the ~125-line Mandatory Specification Template to references/spec-template.md and the Documentation Standards detail to references/documentation-standards.md, leaving concise pointers in SKILL.md.

Fix the broken `` ` ` `` fence in template section 12 (Examples & Edge Cases) and restate or inline the AGENTS.md readiness-score rubric weights so the Phase 6 self-assessment is executable without an external file.

DimensionReasoningScore

Conciseness

The ~315-line body has substantial padding and repetition: the "Dynamic Persona Activation [CRITICAL SYSTEM OVERRIDE]" theatrics, Scope Detection explained three times, Lazy Creation and the ADR triple-gate each stated twice, and the handoff procedure duplicated in both Core Directive 9 and Phase 6. It is above a 1 because it does not explain basic concepts Claude already knows, but the redundancy and persona overhead are clearly noticeable verbosity.

2 / 5

Actionability

The skill provides concrete, executable guidance: an exact refusal phrase, verbatim handoff prompts, the spec-[purpose]-[name].md naming convention, a full mandatory template, a concrete remediation-status markdown block, and example technical questions with recommendations. Minor gaps (broken `` ` ` `` code fences in template section 12, the self-assessment relying on AGENTS.md rubrics that are only referenced, not restated) keep it below a 5.

4 / 5

Workflow Clarity

Phases 1-6 are clearly sequenced with explicit checkpoints: assumption surfacing before drafting, compliance verification before file generation, conflict detection against existing ADRs, and a full audit-remediation feedback loop with re-scoring and conditional routing. Minor issues (the 'Context Check Protocol' bullet is misplaced under Directive 8, and 'Surface Assumptions Immediately' sits in mild tension with Phase 3's 'Fast-Track Synthesis') prevent a 5.

4 / 5

Progressive Disclosure

The body has reasonable section structure but no bundle files exist at all: the ~125-line Mandatory Specification Template and the Documentation Standards section are inlined content that clearly belongs in references/ files. It is above a 2 because headers and phases do organize the content, but the monolithic 315-line layout with zero one-level-deep references keeps it at 3.

3 / 5

Total

13

/

20

Passed

Description

53%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 specific and third-person with a clear statement of what the skill produces, but it entirely lacks a "Use when" trigger clause and natural trigger vocabulary, limiting discoverability. Adding explicit trigger conditions (e.g., transitioning from a PRD to technical design, or when asked to write/update a spec) would raise both completeness and trigger-term quality.

Suggestions

Add a 'Use when...' clause (e.g., 'Use when translating a PRD or user brief into a technical spec, or when updating an existing spec in /spec/') to fix the missing trigger guidance that caps completeness at 3.

Include natural user phrasings as trigger terms such as 'write a spec', 'technical design', 'data contracts', or 'requirements' so the description matches what users actually say.

Mention the distinctive inputs (PRD, audit report) to sharpen distinction from sibling SDLC skills like planning or clarification skills.

DimensionReasoningScore

Specificity

"Generates or updates highly detailed, machine-readable technical specification documents" names the domain and exactly two concrete actions (generate, update), matching the anchor for 1-2 concrete actions without comprehensive coverage. It is not a 4 because no additional specific actions or outputs are enumerated.

3 / 5

Completeness

The description clearly answers "what" (generates/updates spec documents in /spec/) but contains no "Use when..." clause or any trigger guidance, which caps completeness at 3 per the judging guidelines. It is above a 2 because the "what" is specific, not vague.

3 / 5

Trigger Term Quality

Relevant keywords like "technical specification documents", "/spec/", and "machine-readable" are present, but common natural variations users would say ("write a spec", "technical design", "PRD", "requirements doc") are missing. Not a 4 because keyword coverage is thin rather than good-with-few-gaps.

3 / 5

Distinctiveness Conflict Risk

"Technical specification documents in the /spec/ directory" carves out a mostly distinct niche with only minor overlap risk against closely related documentation or planning skills. Not a 5 because the description does not differentiate it from sibling SDLC skills or general technical-design doc skills.

4 / 5

Total

13

/

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

glenrioariesto/social-content-studio

Path

.agents/skills/sdlc-define-specs/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.