CtrlK
BlogDocsLog inGet started
Tessl Logo

technical-design-doc-creator

Creates comprehensive Technical Design Documents (TDD) with mandatory and optional sections through interactive discovery. Use when user asks to "write a design doc", "create a TDD", "technical spec", "architecture document", "RFC", "design proposal", or needs to document a technical decision before implementation. Do NOT use for README files, API docs, or general documentation (use docs-writer instead).

59

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Medium

Suggest reviewing before use

Fix and improve this skill with Tessl

tessl review fix ./packages/skills-catalog/skills/(creation)/create-technical-design-doc/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

52%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's guidance is genuinely actionable — a clear interactive workflow, concrete question payloads, complete section templates, and validation checklists. However, it is severely bloated (52KB, ~1480 lines) with trilingual duplication, worked example data, time-sensitive dates, and explanations of known concepts, and it makes no use of progressive disclosure: everything is inlined in SKILL.md with zero reference files.

Suggestions

Move the 20 section templates, the per-language prompt scripts, and the header-translation table into references/ files (e.g. references/section-templates.md, references/interview-scripts.md) and keep SKILL.md as a concise overview pointing to them — this addresses both the progressive_disclosure and conciseness failures.

Cut content Claude already knows: the security best-practices checklist (input validation, SQL injection, XSS), compliance definitions (GDPR, PCI DSS, LGPD), and the glossary-style explanations — retain only the skill-specific rules (e.g. 'Security is MANDATORY for payments/auth/PII').

Remove fabricated time-sensitive data (hardcoded dates like '2026-02-04', 'ETA: 2026-02-10', status emojis in 'complete' roadmap rows) from the templates, and replace the duplicated English/Portuguese/Spanish blocks with the single translation rule ('generate in the user's language') plus one short example.

Fix the workflow inconsistencies: reconcile the project-size section maps with the 1-20 section numbering, and renumber 'Critical Sections' (8-11) as a coherent continuation of the section list.

DimensionReasoningScore

Conciseness

At ~1480 lines, the body is heavily padded: full trilingual prompt scripts (English/Portuguese/Spanish for every workflow step), a section-header translation table, 20 fully worked templates filled with fake Stripe-specific data and time-sensitive dates ('2026-02-04', 'ETA: 2026-02-10'), plus explanations of concepts Claude already knows (input validation, SQL injection prevention, GDPR/PCI DSS definitions). It is noticeably beyond the 'several unnecessary explanations' of a 3, though much of the bulk is template material rather than tutorial prose, keeping it above a 1.

2 / 5

Actionability

Concrete and executable in most places: exact AskQuestion JSON payloads, copy-paste markdown section templates, per-project-type section matrices, validation checklists, and BAD/GOOD anti-pattern pairs. Not a 5 because some guidance is environment-specific and unverifiable ('AskQuestion tool', 'Confluence Assistant skill') and the templates remain placeholder skeletons rather than complete worked examples.

4 / 5

Workflow Clarity

The 6-step interactive workflow (gather -> validate mandatory info -> check critical sections -> offer suggested sections -> generate -> offer publishing) is clearly sequenced with explicit validation checklists and 'if missing, ask' feedback branches. Not a 5 due to inconsistencies: the project-size maps ('Use sections 1-11, 15, 18' then 'Offer: Success Metrics', which is section 12) conflict with the section numbering, and critical sections are numbered 8-11 under a separate heading.

4 / 5

Progressive Disclosure

No bundle files exist at all; the ~1000 lines of section templates and trilingual prompt scripts are exactly the content that belongs in references/ files, and the only 'References' section is external URLs. Headers make it navigable (above a 1), but disclosure failure is near-total — virtually the whole body should be split into one-level-deep reference files rather than 'some inline content that could be separate' as at a 3.

2 / 5

Total

12

/

20

Passed

Description

87%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 strong description in third-person voice with a clear what/when pair, multiple natural trigger phrases, and an explicit disambiguation boundary against docs-writer. The only weakness is minor: a few common synonym phrasings ('tech spec', 'design document') are absent, and the capability list is one deliverable with modifiers rather than several distinct actions.

DimensionReasoningScore

Specificity

The description names the deliverable ('Technical Design Documents (TDD)') and concrete mechanisms ('mandatory and optional sections', 'interactive discovery'). It falls short of the 5 anchor because the 'what' is a single deliverable with modifiers rather than a list of multiple distinct operations, and exceeds the 3 anchor's 1-2 concrete actions.

4 / 5

Completeness

Explicitly answers both 'what' ('Creates comprehensive Technical Design Documents (TDD) with mandatory and optional sections through interactive discovery') and 'when' ('Use when user asks to... or needs to document a technical decision before implementation') with concrete trigger phrases, matching the 5 anchor exactly.

5 / 5

Trigger Term Quality

Quotes multiple natural trigger phrases users would say: 'write a design doc', 'create a TDD', 'technical spec', 'architecture document', 'RFC', 'design proposal'. Not a 5 because common variants like 'tech spec', 'design document', or 'HLD' are missing.

4 / 5

Distinctiveness Conflict Risk

Clear niche (technical design documents) with distinct triggers, plus an explicit negative boundary ('Do NOT use for README files, API docs, or general documentation (use docs-writer instead)') that minimizes conflict risk with adjacent documentation skills.

5 / 5

Total

18

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (1485 lines); consider splitting into references/ and linking

Warning

referenced_paths_exist

Referenced path issues: 4 missing

Warning

Total

14

/

16

Passed

Repository
tech-leads-club/agent-skills
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.