Agent skill · Backend & API

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

tech-leads-clubgithub.com/tech-leads-clubGitHub ↗
claude-codecopilotcursorNOASSERTION
Install
npx skills add tech-leads-club/agent-skills --skill create-technical-design-doc --agent claude-code

Same command for any agent — swap --agent for codex, cursor, copilot.

Facts
Files in the skill folder: 2
SKILL.md size: 50 KB
Bundled scripts: none
Path: packages/skills-catalog/skills/(creation)/create-technical-design-doc/SKILL.md
Open the folder on GitHub →
Where it comes from
Stars: 4,983
Language: TypeScript
Read our review of the source →

Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.

Review
written from the skill's own SKILL.md · Aug 5, 2026

What it does

Creates comprehensive Technical Design Documents (TDDs) 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).

How it works

The skill guides the user through structured TDD creation by:

  • Initiating with a user prompt to determine language and project context
  • Collecting mandatory information (e.g., problem statement, scope, high-level technical approach, risks) and validating presence
  • Identifying the project type (e.g., payment/auth/production) to determine mandatory critical sections
  • Recommending optional sections (success metrics, glossary, alternatives, dependencies, performance, open questions) based on project size and needs
  • Generating a Markdown-formatted TDD document with sections aligned to industry patterns (Context/Problem/Scope, Technical Solution, Risks, Implementation Plan, Security, Testing, Monitoring, Rollback, etc.)
  • Offering to publish to Confluence if the user has that skill available

When to use it

Use this skill when users request to create a design document or document a technical decision prior to implementation. It is intended for architectural decisions and contracts, not implementation details or code.

What it can touch

The skill references tools and integration points such as:

  • Language adaptation to match user input language
  • Optional Confluence publishing workflow if Confluence Assistant is available

Caveats

  • Produces content in the user’s language and translates headers/prose accordingly
  • Avoids including implementation code or framework-specific snippets; emphasizes high-level architectural decisions
  • Sections are included or prompted based on the project type and mandatory requirements; if a section is not applicable or missing, it may be omitted
From the SKILL.md

# Technical Design Doc Creator You are an expert in creating Technical Design Documents (TDDs) that clearly communicate software architecture decisions, implementation plans, and risk assessments following industry best practices. ## When to Use This Skill Use this skill when: - User asks to "create a TDD", "write a design doc", or "document technical design" - User asks to "criar um TDD", "escrever um design doc", or "documentar design técnico" - Starting a new feature or integration project - Designing a system that requires team alignment - Planning a migration or replacement of existing systems - User mentions needing documentation for stakeholder approval - Before implementing significant technical changes ## Language Adaptation **CRITICAL**: Always generate the TDD in the **same language as the user's request**. Detect the language automatically from the user's input and generate all content (headers, prose, explanations) in that language. **Translation Guidelines**: - Translate all section headers, prose, and explanations to match user's language - Keep technical terms in English when appropriate (e.g., "API", "webhook", "JSON", "rollback", "feature flag") - Keep code exampl

What's inside
Steps it walks through
  1. When to Use This Skill
  2. Language Adaptation
  3. Industry Standards Reference
  4. High-Level vs Implementation Details
  5. ✅ What to Include (High-Level)
  6. ❌ What to Avoid (Implementation Code)
  7. Examples: High-Level vs Implementation
  8. Guideline: Ask "Will This Change?"
  9. Document Structure
  10. Mandatory Sections (Must Have)
  11. Critical Sections (Ask if Missing)
  12. Suggested Sections (Offer to User)
  13. Project Size Adaptation
  14. Small Project (< 1 week)
Ships with 1 file
  • README.md
More from agent-skills
All skills →
About this skill
What does the technical-design-doc-creator skill do?

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

How do I install it?

Run `npx skills add tech-leads-club/agent-skills --skill create-technical-design-doc --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.

Where does this skill come from?

From tech-leads-club/agent-skills, a repository with 4,983 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.

Is a popular skill a good skill?

Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.

Keep going