ddd-refiner

Name: ddd-refiner
Author: techygarg

165stars12forks

How to install ddd-refiner?

techygarg/lattice/ddd-refiner

$npx -y skills add techygarg/lattice --skill ddd-refiner

Installs into the current project.

Summary

Facilitate a structured conversation to define DDD guardrails for domain design within a repository. Produces a formal ddd-principles.md document that the domain-driven-design atom will use as its override. Use when setting up domain design principles, defining aggregate rules, o

Files · 1

View on GitHub

SKILL.md

1	# DDD Refiner
2
3	## What This Produces
4
5	- Output: `.lattice/standards/ddd-principles.md` (or custom path from `.lattice/config.yaml` → `paths.ddd_principles`)
6	- Two modes:
7	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the defaults. The domain-driven-design atom reads its embedded defaults first, then applies this document's sections on top. This is the expected common case.
8	- Override (`mode: override`): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams with fundamentally different domain modeling principles.
9	- Default mode: Overlay -- produces only what the user wants to change
10	- Config key: `paths.ddd_principles` in `.lattice/config.yaml`
11	- Template: Read `./assets/template.md` for the full document structure, default content, and interview guidance comments
12
13	## Scope Clarification
14
15	This skill defines the rules of domain crafting, not the domain model itself. The domain model evolves through features; this document defines the guardrails. It covers DDD tactical patterns only -- not strategic DDD (no context mapping, no microservice topology, no bounded context integration).
16
17	## Before You Begin
18
19	### Check for existing documents
20
21	Before starting the interview, check whether a custom document already exists:
22
23	1. Read `.lattice/config.yaml` -- does `paths.ddd_principles` point to a file?
24	2. If yes, read that file. Ask the user:
25	- "You already have a custom DDD principles document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
26	- Revise: Load the existing document, walk through only the sections the user wants to change, and update in place.
27	- Start fresh: Proceed with the full interview flow below.
28	- Add to it: Skip to the "New Sections" part of the interview.
29	3. If no config or no existing document, proceed with the full interview flow.
30
31	### Scan the repository
32
33	Look for signals that inform the conversation:
34
35	- Domain folder: Does a `domain/` (or `core/`, `model/`) folder exist? What's inside it?
36	- Existing aggregates: Are there entities, value objects, aggregate roots? How are they structured?
37	- Anemic patterns: Are entities data holders or do they have behavior?
38	- Identity patterns: Typed IDs, raw UUIDs, database-generated IDs?
39	- Event patterns: Are domain events used? What naming convention?
40	- Architecture docs: Any existing DDD documentation, ADRs, domain glossaries?
41
42	Share relevant findings with the user at the start: "I noticed your project already has [X patterns]. I'll use that as context."
43
44	If the project is new with no code, proceed with pure defaults as the starting point.
45
46	## Choosing the Mode
47
48	The first decision in the conversation. Present the three options:
49
50	"How would you like to define your DDD principles?
51
52	1. Customize specific sections (overlay) -- Keep the defaults and change only what differs for your project. This produces a slim document. Most teams choose this.
53	2. Define everything from scratch (override) -- Walk through all sections and produce a comprehensive standalone document.
54	3. Add project-specific sections only (overlay with additions) -- Keep all defaults as-is and add new sections for your team's specific rules (e.g., ubiquitous language glossary, bounded context boundaries).
55
56	The defaults cover standard DDD tactical patterns well. Option 1 is recommended unless your domain modeling approach is fundamentally different."
57
58	Map the choice:
59	- Options 1 and 3 → `mode: overlay`
60	- Option 2 → `mode: override`
61
62	## Facilitation Approach
63
64	### Conversation style
65
66	- One section at a time. Do not dump all questions at once. Walk through the template sequentially.
67	- Defaults-first. For each section, briefly summarize the default, then ask if it matches. Do not read the entire default verbatim -- summarize the key points and ask.
68	- Record decisions, not discussion. The output document reads as a specification, not meeting notes. "We discussed X and decided Y" is wrong. "Y" is right.
69	- Probe, don't interrogate. Use the probing questions in the template guidance comments as follow-ups when the user's answer is ambiguous, not as a checklist.
70
71	### For overlay mode
72
73	This should be fast. Many sections will be "keep as-is."
74
75	1. Present each section's default briefly (a 2-3 sentence summary, not full content).
76	2. Ask: "Does this match your project, or would you like to change it?"
77	3. If the user says it mat

People who liked this also viewed

6 picks

Type

ddd-refiner

165stars12forks

View on GitHub

How to install ddd-refiner?

techygarg/lattice/ddd-refiner

$npx -y skills add techygarg/lattice --skill ddd-refiner

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# DDD Refiner
2
3	## What This Produces
4
5	- Output: `.lattice/standards/ddd-principles.md` (or custom path from `.lattice/config.yaml` → `paths.ddd_principles`)
6	- Two modes:
7	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the defaults. The domain-driven-design atom reads its embedded defaults first, then applies this document's sections on top. This is the expected common case.
8	- Override (`mode: override`): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams with fundamentally different domain modeling principles.
9	- Default mode: Overlay -- produces only what the user wants to change
10	- Config key: `paths.ddd_principles` in `.lattice/config.yaml`
11	- Template: Read `./assets/template.md` for the full document structure, default content, and interview guidance comments
12
13	## Scope Clarification
14
15	This skill defines the rules of domain crafting, not the domain model itself. The domain model evolves through features; this document defines the guardrails. It covers DDD tactical patterns only -- not strategic DDD (no context mapping, no microservice topology, no bounded context integration).
16
17	## Before You Begin
18
19	### Check for existing documents
20
21	Before starting the interview, check whether a custom document already exists:
22
23	1. Read `.lattice/config.yaml` -- does `paths.ddd_principles` point to a file?
24	2. If yes, read that file. Ask the user:
25	- "You already have a custom DDD principles document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
26	- Revise: Load the existing document, walk through only the sections the user wants to change, and update in place.
27	- Start fresh: Proceed with the full interview flow below.
28	- Add to it: Skip to the "New Sections" part of the interview.
29	3. If no config or no existing document, proceed with the full interview flow.
30
31	### Scan the repository
32
33	Look for signals that inform the conversation:
34
35	- Domain folder: Does a `domain/` (or `core/`, `model/`) folder exist? What's inside it?
36	- Existing aggregates: Are there entities, value objects, aggregate roots? How are they structured?
37	- Anemic patterns: Are entities data holders or do they have behavior?
38	- Identity patterns: Typed IDs, raw UUIDs, database-generated IDs?
39	- Event patterns: Are domain events used? What naming convention?
40	- Architecture docs: Any existing DDD documentation, ADRs, domain glossaries?
41
42	Share relevant findings with the user at the start: "I noticed your project already has [X patterns]. I'll use that as context."
43
44	If the project is new with no code, proceed with pure defaults as the starting point.
45
46	## Choosing the Mode
47
48	The first decision in the conversation. Present the three options:
49
50	"How would you like to define your DDD principles?
51
52	1. Customize specific sections (overlay) -- Keep the defaults and change only what differs for your project. This produces a slim document. Most teams choose this.
53	2. Define everything from scratch (override) -- Walk through all sections and produce a comprehensive standalone document.
54	3. Add project-specific sections only (overlay with additions) -- Keep all defaults as-is and add new sections for your team's specific rules (e.g., ubiquitous language glossary, bounded context boundaries).
55
56	The defaults cover standard DDD tactical patterns well. Option 1 is recommended unless your domain modeling approach is fundamentally different."
57
58	Map the choice:
59	- Options 1 and 3 → `mode: overlay`
60	- Option 2 → `mode: override`
61
62	## Facilitation Approach
63
64	### Conversation style
65
66	- One section at a time. Do not dump all questions at once. Walk through the template sequentially.
67	- Defaults-first. For each section, briefly summarize the default, then ask if it matches. Do not read the entire default verbatim -- summarize the key points and ask.
68	- Record decisions, not discussion. The output document reads as a specification, not meeting notes. "We discussed X and decided Y" is wrong. "Y" is right.
69	- Probe, don't interrogate. Use the probing questions in the template guidance comments as follow-ups when the user's answer is ambiguous, not as a checklist.
70
71	### For overlay mode
72
73	This should be fast. Many sections will be "keep as-is."
74
75	1. Present each section's default briefly (a 2-3 sentence summary, not full content).
76	2. Ask: "Does this match your project, or would you like to change it?"
77	3. If the user says it mat

People who liked this also viewed

6 picks

Type