Convert natural language requirements (PRD) into AI-friendly DDD domain design documents in Markdown. Use when the user provides a PRD, requirement doc, or business description and wants a DDD domain model, entity/aggregate design, ER diagram, domain logic placement, or sequence/flow diagrams. Produces structured output that AI agents can directly use for implementation.

Convert natural language requirements (PRD) into AI-friendly DDD domain design documents in Markdown. Use when the user provides a PRD, requirement doc, or b...

Security Scan

The skill is an instruction-only DDD/PRD→design template that only reads the provided PRD and included guidance files and produces Markdown design docs; its requirements and instructions are consistent with its stated purpose.

Purpose & Capability

The name/description match the included SKILL.md, phase guide, and template: the skill's goal is to transform PRDs into DDD design docs. It requests no binaries, no environment variables, and no credentials, which is proportional and expected for a purely authoring/template skill.

Instruction Scope

Runtime instructions are limited to reading the user-provided PRD and the two included guidance files, executing the documented phases, producing Markdown with Mermaid diagrams, and saving the result. The instructions do not request system secrets, unrelated filesystem paths, or network endpoints; they specify writing output to docs/design/<feature>-ddd-design.md, which is appropriate for a doc-generation skill.

Install Mechanism

No install spec and no code files — instruction-only — so nothing is downloaded or written to disk by an installer. This is the lowest-risk install model and is proportionate for the described functionality.

Credentials

The skill declares no required environment variables, no primary credential, and no config paths. The SKILL.md does not reference hidden env vars or credentials. The lack of requested secrets is appropriate for a documentation/template skill.

Persistence & Privilege

The skill instructs the agent to save output to docs/design/<feature>-ddd-design.md; writing files in the agent workspace is expected here. always:false (default) and normal autonomous invocation settings are used. This is reasonable, but users should be aware the agent will create files in the workspace when the skill runs.

Assessment

This skill appears internally consistent and only uses the provided PRD and local template/guide files to generate a Markdown DDD design doc. Before installing/using it: (1) do not include sensitive secrets or PII in the PRD you hand to the skill (the skill will consume the PRD text to produce the doc); (2) confirm you are comfortable with the agent writing files to your workspace at docs/design/<feature>-ddd-design.md; (3) review any generated API or external-system entries in the output to ensure they don't unintentionally expose credentials or environment-specific endpoints. If you need the agent to run network calls, connect to external services, or access private repos, expect additional permissions/credentials would be required — none are requested here.

PRD to DDD Domain Design

Convert PRD / natural language requirements into a structured DDD design document.

When to Use

• User provides a PRD, requirement document, or business description
• User asks: "把需求转成DDD设计" / "领域建模" / "domain modeling from requirement"
• Before implementation — this is the first step in the AI development workflow

Relationship to Other Skills

• design-to-plan: After this skill produces the design doc → split into implementation plans
• ddd-domain-model / ddd-cross-layer: Implementation patterns → use after design is finalized

Resources

File	Role	When to Read
This file (SKILL.md)	Map — workflow, phases, output rules	Always (auto-loaded)
phase-guide.md	How-to — analysis heuristics, design criteria, identification rules	When executing each phase
ddd-design-template.md	Template — output section structure with table formats	When writing the design doc

---

Workflow

PRD / Natural Language
        │
        ▼
  Phase 0 → 1 → 2 → 3 → 4 → 4.5 → 5 → 5.5 → 6
        │
        ▼
  Output: docs/design/<feature>-ddd-design.md

Phase Summary

Phase	Name	What to Produce	Key Input
0	Event Storming	Actor → Command → Aggregate → Event → Policy flow	PRD text
1	Domain Discovery	Ubiquitous language glossary, domain events, business rules	PRD nouns/verbs
2	Strategic Design	Bounded contexts, context mapping	Phase 0-1 results
3	Tactical Design	Entities, VOs, aggregates, relationships	Phase 1-2 results
4	ER Modeling	Mermaid ER diagram (PK/FK only)	Phase 3 entities
4.5	Database Schema	Table mapping, columns, indexes, constraints	Phase 3-4 entities
5	Logic Placement	Entity/VO logic, Gateway/Repo interfaces, Domain Services	Phase 3 + PRD rules
5.5	Cross-Layer Contracts	REST API, Client DTOs, AppService API, Infra adapters	Phase 5 results
6	Behavior Modeling	State machines, sequence diagrams, flowcharts, event flows	Phase 0 + 5

For detailed instructions on each phase (extraction rules, identification heuristics, design criteria), read phase-guide.md.

---

Execution Steps

1. Read the PRD document provided by user
2. Read phase-guide.md for analysis heuristics
3. Execute phases 0-6 sequentially, using ddd-design-template.md as the output structure
4. Run the Quality Checklist below before finalizing
5. Save to docs/design/<feature-name>-ddd-design.md

---

Output Rules

• Pure Markdown with Mermaid diagrams
• Chinese for business descriptions, English for technical terms (class names, method signatures)
• Align naming and layer placement with ddd-architecture rule
• Align domain purity with ddd-domain-layer rule
• Every entity must have behaviors (no anemic model)
• Every aggregate must list invariants
• Every domain logic item must have placement rationale
• Database schema must map all entities/VOs to tables with complete columns
• Cross-layer contracts must be defined with input/output types

---

Quality Checklist

Before finalizing the document, verify:

Event Storming & Discovery (Phase 0-1)

• All Actors, Commands, Specs, Events, Policies identified
• Command → Aggregate → Event mapping is complete
• All business nouns mapped to entities or value objects
• All business rules captured with rule IDs
• Ubiquitous language glossary includes Package column

Tactical Design (Phase 2-3)

• Aggregates are small with clear boundaries
• No cross-aggregate direct object references (use ID)
• Entity behaviors are rich (no anemic model)
• State machines documented for stateful entities
• Naming follows project DDD conventions

Data & Logic (Phase 4-5)

• ER diagram only shows PK/FK, consistent with entity/VO tables
• Entity → Table mapping covers all entities and value objects
• Table Detail includes all columns with type, nullable, default
• Indexes defined for FK columns, frequent queries, unique keys
• Domain logic placement has clear rationale for every item
• Domain Service design decisions documented with alternatives

Cross-Layer & Behavior (Phase 5.5-6)

• REST API endpoints listed with URL, HTTP method, request/response types
• Client DTOs (Request/Response) key fields defined
• AppService methods listed with Command input and DTO output
• Infrastructure adapter-to-gateway mapping is complete
• Sequence diagrams cover all core use cases
• Flowcharts cover complex branching rules (2+ paths)