mcpField
D
design-doc

design-doc

github.com/diskd-aiDevelopment32368 installsUpdated 40w ago
Repository

About design-doc

A skill for writing structured technical design documents that explain system behavior, implementation plans, and acceptance criteria. It guides authors through context gathering, drafting, clarification, and review using a referenced template.

Key features

  1. 01Structured design document workflow
  2. 02Template-based section guidance
  3. 03Testable acceptance criteria
  4. 04Implementation and testing outlines
  5. 05Scope and non-goal definition

Use cases

  1. 01Documenting a new feature's design
  2. 02Turning system requirements into an implementation outline
  3. 03Reviewing acceptance criteria for testability

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/diskd-ai/design-doc --skill design-doc

After installing, type/design-docin Claude Code to confirm it loaded.

Bundled filesreferences/template.mdREADME.md

Details

From the project README

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

Comments

Markdown supported