From avila-tek-skill-pack
Generates a Technical Design Document (TDD) from a Spec Funcional and domain document. Use whenever the user wants to create a technical design doc, TDD, design doc, architecture doc, "diseño técnico", or "documento de diseño". Trigger phrases: "generate a technical design", "write a design doc", "create a TDD", "document the technical solution", "genera el diseño técnico", "crea el TDD". Requires a Spec Funcional as input — do not generate a TDD without one. Covers: problem statement, solution with ASCII flows and diagrams, component architecture, data model, API design, security, and integrations. NOT a functional spec — use skill-1 instead.
npx claudepluginhub avila-tek/avila-tek-skill-packThis skill uses the workspace's default tool permissions.
Generates a focused **Technical Design Document (TDD)** from a Spec Funcional and domain document.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Generates a focused Technical Design Document (TDD) from a Spec Funcional and domain document. The TDD owns architecture, data model, APIs, security, and integrations — not functional flows or scope (those live in the Spec and Epics).
Audience: Engineering teams, architects, tech leads.
Output format: .docx by default; .md if requested.
Language: Always English.
Before doing anything, ask the tech lead:
"Are you creating the TDD before the epics (architecture-first) or after (epics already exist)?"
docs/epics/ to populate section 4.3 accurately.Both paths require a Spec Funcional.
docs/project_context.mddocs/domain_model.md — required if it exists. Use entity definitions, invariants, state lifecycles, and DBML schema from this document to inform the data model and technical rules sections.docs/epics/ — only if "TDD after epics" path.Read the Spec Funcional:
cat /path/to/spec_funcional.md
# or for uploaded files:
pandoc /mnt/user-data/uploads/<file>.docx -t markdown
From the Spec, identify:
Do NOT copy functional flows — those stay in the Spec. Mark unknowns as [TO BE DEFINED].
Read the canonical template before generating:
cat /mnt/skills/user/technical-design-document/references/template.md
Follow the template structure exactly. All diagrams must be ASCII only — no Mermaid.
Output path: docs/epics/E-XXX_<slug>/tdd.md
The TDD relationship with epics is strictly 1:1 — one TDD per epic, one epic per TDD. If the user describes a feature that spans multiple epics, generate a separate TDD for each epic.
tdd.md there.docs/epics/E-XXX_<slug>/) before writing the file. The epic generator (skill-3) will add epic.md and stories/ later.If the user requests .docx, read /mnt/skills/public/docx/SKILL.md before generating.
Key formatting:
docs/epics/E-XXX_<slug>/tdd.docxpresent_files with the output path.Before delivering, verify:
- **Term**: Definition), not a tabledocs/domain_model.md for entity definitions, invariants, and DBML schema[TO BE DEFINED] — never inventeddocs/epics/E-XXX_<slug>/tdd.md (not to docs/ root or outputs folder)