design-doc

design-doc

Create technical design documents for new features, systems, refactoring plans, API designs, and database schemas. Use when asked to write a design doc, TRD (technical requirements document), RFC, or system design document. Triggers on requests like "write a design doc for X", "design the Y feature", "create a technical spec", or "plan the architecture for Z".

1estrellas
0forks
Actualizado 1/24/2026
SKILL.md
readonlyread-only
name
design-doc
description

Create technical design documents for new features, systems, refactoring plans, API designs, and database schemas. Use when asked to write a design doc, TRD (technical requirements document), RFC, or system design document. Triggers on requests like "write a design doc for X", "design the Y feature", "create a technical spec", or "plan the architecture for Z".

Technical Design Document Skill

Create structured technical design documents that communicate system behavior, implementation approach, and acceptance criteria.

Workflow

  1. Gather context: Understand the feature/system scope, constraints, and goals
  2. Draft structure: Use template from references/template.md
  3. Fill sections: Work through each section, asking clarifying questions as needed
  4. Review: Ensure acceptance criteria are testable and implementation outline is actionable

Template

See references/template.md for the full template structure and section guidelines.

Core sections:

  • Context and motivation: Problem statement, goals, non-goals
  • Implementation considerations: Constraints and design principles
  • High-level behavior: End-to-end system behavior
  • Domain-specific sections: Adapt to feature type (discovery, validation, API, state, rendering)
  • Error handling and UX: Error surfacing and recovery
  • Future-proofing: Design for extensibility
  • Implementation outline: Step-by-step approach
  • Testing approach: Unit, integration, manual tests
  • Acceptance criteria: Testable conditions for "done"

Writing Guidelines

  • Use --- underlines for section headers (Setext style)
  • Write in present tense for behavior ("loads", "validates", "returns")
  • Be specific: "max 100 chars" not "reasonable length"
  • Include concrete examples where behavior varies
  • Non-goals are as important as goals - prevent scope creep
  • Acceptance criteria must be verifiable, not subjective

You Might Also Like

Related Skills

verify

verify

243K

Use when you want to validate changes before committing, or when you need to check all React contribution requirements.

facebook avatarfacebook
Obtener
test

test

243K

Use when you need to run tests for React core. Supports source, www, stable, and experimental channels.

facebook avatarfacebook
Obtener

Use when feature flag tests fail, flags need updating, understanding @gate pragmas, debugging channel-specific test failures, or adding new flags to React.

facebook avatarfacebook
Obtener

Use when adding new error messages to React, or seeing "unknown error code" warnings.

facebook avatarfacebook
Obtener
flow

flow

243K

Use when you need to run Flow type checking, or when seeing Flow type errors in React code.

facebook avatarfacebook
Obtener
flags

flags

243K

Use when you need to check feature flag states, compare channels, or debug why a feature behaves differently across release channels.

facebook avatarfacebook
Obtener