do-design

Generates architecture, API contract, and data model design documents from requirement specifications.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/khoavu882/do-flow --skill do-design-khoavu882
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: do-design
Source: https://github.com/khoavu882/do-flow/tree/main/core/shared/skills/do-design
Command: npx skills add https://github.com/khoavu882/do-flow --skill do-design-khoavu882

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Turning a written requirement into concrete system-shape decisions (architecture, API contracts, data models) is often ad hoc and undocumented. This Skill converts a requirement.md into structured design.md, specs.md, and data-model.md artifacts with validated task classification and recorded design rationale. ## Core Features & Use Cases - System-Shape Design: Produces C4 context/container diagrams (rendered as Mermaid flowcharts), component boundaries, API/interface contracts with numbered IC-### IDs, and data models. - Structured Clarification Loop: Batches design-level ambiguities into question rounds, logs each round to design-<NN>-question.md files, and records deferred decisions as assumptions. - Workflow Integration: Validates the proposed task class against the DoFlow runtime, batches evidence and claims, and records the stage handoff for the next phase. - Use Case: After brainstorming requirements for a new feature, run this Skill to produce the architecture narrative, interface contracts, and data model that the planning phase will cite by stable contract IDs. ## Quick Start Ask the AI to design the architecture, API contracts, and data model for the current feature based on its requirement.md.

Frequently Asked Questions about do-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I turn a requirements document into a system design?▼

Run this Skill after requirement.md exists; it reads the requirements, resolves ambiguities through a clarification loop, and writes design.md, specs.md, and data-model.md covering architecture, interface contracts, and data models.

What is the difference between do-design and do-plan?▼

do-design covers system-shape decisions like architecture, API contracts, and data models, while do-plan covers implementation approach and task decomposition. Design answers what the system looks like; planning answers how to build it.

Can I generate a design document without a requirement.md file?▼

Yes, but the Skill warns that no requirement.md exists and offers to run the brainstorming phase first. This precondition is advisory and skippable, not a hard gate.

Why are interface contracts split into a separate specs.md file?▼

Separating contracts into specs.md gives each one a numbered IC-### identifier, so downstream planning and implementation tasks can cite stable contract IDs instead of fragile narrative paragraphs in design.md.

When should I skip creating a design document?▼

Skip it for bug fixes or trivial edits, since those task classes have no design stage in their workflow. Producing a design.md for them creates an artifact the workflow never reads.