Document ddd

Skill kt3k/skills/skills/document-ddd

Skills for developing software carefully and steadily. Plan tasks, review code, and refine design to improve overall quality.

Install

npx -y skills add kt3k/skills --skill document-ddd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Update or create DDD documentation based on the current state of the codebase. Generates a single DOMAIN.md with context map, glossary, and aggregate documentation.

SKILL.md

2.0 KB, as published. Nobody here has run it

Document DDD Skill

Generate or update Domain-Driven Design documentation to keep it in sync with the current codebase. All documentation is maintained in a single DOMAIN.md file at the project root.

Execution Flow

Assess current state: Check if DOMAIN.md already exists. Read the codebase to understand the current domain model.
Generate/update DOMAIN.md with the following sections:
- Context Map:
  - List all bounded contexts discovered in the codebase
  - Document relationships between contexts (upstream/downstream, shared kernel, anti-corruption layer, etc.)
  - Note integration patterns used
- Glossary:
  - Canonical list of ubiquitous language terms with definitions
  - Update from current code — add new terms, remove obsolete ones, fix inconsistencies
- Aggregates:
  - One section per aggregate root
  - Document: purpose, invariants, entities contained, value objects, domain events emitted
  - Include key code references
Diff and confirm: Before writing, show the user what will be created or changed. Apply changes only after approval.

Output Format

A single file DOMAIN.md at the project root with the following structure:

# Domain Model

## Context Map

...

## Glossary

| Term | Definition | Code Location |
|------|------------|---------------|
| ...  | ...        | ...           |

## Aggregates

### <Aggregate Name>

- **Purpose**: ...
- **Invariants**: ...
- **Entities**: ...
- **Value Objects**: ...
- **Domain Events**: ...

...

Guidelines

Keep documentation concise and developer-focused — not academic.
Reference actual code paths so docs stay grounded.
If DOMAIN.md already exists, update it incrementally rather than replacing wholesale.
Always ask for user confirmation before writing files.