authoring-technical-design — SKILL.md

Variant: standard · When to use: designing how to build one feature/component into a technical design doc (or amending an approved one) — to a bar an engineer can implement from without re-deriving the design.

Overview

This skill is the how-to of writing a strong technical design document (TDD) — the detailed implementation design for one feature or component within an existing system. The PRD says what the product does and the feature-spec says how each feature behaves; the TDD says how this feature will be built — the chosen approach, the components and their responsibilities, the control + data flow, the key interfaces, the significant logic, the failure modes, the cross-cutting concerns (security/privacy/observability), the alternatives weighed, the testing, and the rollout. This skill carries the producer's judgment — a design-research method and an implementability bar — not the section list. It assumes two collaborators: a technical-design template tool that supplies the section structure, and a deep-research capability to ground the design in evidence. The producer is handed the approved PRD + feature-spec (and, where they exist, the architecture-doc + API spec + data-model) and must elaborate how to build the feature — never emit a generic skeleton. The bar to clear: an engineer can implement the feature from the doc without re-deriving the design, and the chosen approach is justified against at least one real alternative. The skill's bar is single-sourced with its reviewer gate, reviewing-technical-design — the author targets exactly what the gate asserts, so they cannot drift.

When to activate

• Authoring a TDD for one feature-spec'd feature/component, designing how it will be built within the existing system.
• Deciding and documenting the implementation approach: component decomposition, control/data flow, interfaces, detailed logic, failure modes, observability, testing, and rollout.
• Amending an approved TDD as a versioned delta (a chosen approach proves unworkable mid-build, a feature-spec behavior is corrected, a new failure mode appears) — see Step 6.
• Filling a technical-design template with researched, decision-complete content traced to the feature's requirements.

Do NOT activate when: