AgentSkillsCN

TDD Generator

为某个功能生成技术设计文档（TDD）或轻量级技术规格说明书。支持“轻量模式”（适用于简单变更，约 3 页规格书）与“重量模式”（适用于复杂功能，提供完整的架构文档）。适用于用户需要技术实现规格、功能架构决策，或面向开发者的设计文档时使用。可通过“创建 TDD”、“撰写技术规格”、“为该功能进行技术设计”或“架构文档”等请求触发。

SKILL.md
--- frontmatter
name: TDD Generator
description: Generate a Technical Design Document (TDD) or lightweight Tech Spec for a feature. Supports LIGHT mode (~3-page spec for simple changes) and HEAVY mode (full architecture document for complex features). Use when the user needs technical implementation specs, architecture decisions for a feature, or a developer-facing design document. Triggers on requests like "create a TDD", "write a tech spec", "technical design for this feature", or "architecture document".

Technical Design Document (TDD) Generator

Role

Senior Solutions Architect. Focuses strictly on the DELTA — what is changing, what is new. Communicates via Mermaid diagrams rather than prose where possible. Excludes cross-cutting concerns governed by global standards unless explicitly changed.

Objective

Generate a technical document that gives development teams everything needed to implement the feature described in the FSD / Tech Spec inputs. Focus on what is new or changed only.

Process

Step 1: Mode Selection

Determine LIGHT or HEAVY mode:

ConditionMode
New service or bounded contextHEAVY
Persistent data model changes (new entities)HEAVY
External system integrationsHEAVY
Public API changesHEAVY
Non-trivial async flows or state machinesHEAVY
Everything elseLIGHT

If the mode is not specified by the user or workflow, state your assumption clearly.

Step 2: Process Inputs & Interview

Scenario A: Converting FSD / Specs Read the provided documents. Identify:

  • •What is NEW (new components, entities, endpoints)
  • •What is CHANGED (modified behavior, schema migrations)
  • •What is UNCHANGED (explicitly list, then ignore)

Scenario B: Standalone Request (No Docs) Interview the user to gather context:

  • •Feature: What is being built or changed?
  • •Scope: New service, new endpoints, UI changes, data model changes?
  • •Constraints: Performance targets, tech stack constraints, integration requirements?
  • •Inputs available: FSD, ERD, API Contract, Wireframes?

Step 3: Generate Document

Use the template in references/template.md.

Key generation rules:

  • •Delta only: Do not document the entire existing system. Only what's new or changed.
  • •Mermaid preferred: Use sequenceDiagram, flowchart TD, or erDiagram for all non-trivial flows.
  • •No boilerplate: Omit sections entirely if no delta exists. Reference global standards; do not restate them.
  • •LIGHT mode: Produce ~3 pages. Skip sections 6, 8, 10 unless critical.
  • •HEAVY mode: Full template. All sections that have deltas.
  • •Gap identification: If input artifacts have inconsistencies, document them clearly.

Step 4: Review

Present the document to the user.

  • •Verify architecture decisions are sound.
  • •Confirm all new components are accounted for.
  • •Validate data model changes.

Quality Checklist

  • • Every technical decision traces back to a functional requirement
  • • All NEW entities and API endpoints are detailed
  • • Diagrams used for non-trivial flows (not just prose)
  • • Delta is clearly separated from unchanged system
  • • LIGHT/HEAVY mode is stated and justified