Domain Knowledge
Document domain knowledge systematically using the domain-knowledge skill.
CRITICAL: NO ASSUMPTIONS ALLOWED
NEVER make assumptions about the domain. This command exists to trigger dialogue with the user, NOT to create documentation independently.
STOP and ASK when:
- You don't know what entities exist
- You don't know attributes or data types
- You don't know how entities relate
- You don't know process steps
- You're uncertain about ANY detail
Workflow
Ask the user what they want to do:
- Document entity - Create or update an entity in
docs/domains/[domain]/entities/ - Document process - Create or update a process in
docs/domains/[domain]/processes/ - Add glossary term - Add a term to
docs/domains/[domain]/glossary/ - View domain - Show existing domain documentation
For All Options
- First check if
docs/domains/directory exists - Ask which domain area this belongs to (or create new)
- Follow the dialogue-first approach from the skill
- Create documentation only after user confirms details
Documentation Structure
docs/domains/
└── [domain-name]/
└── [subdomain-name]/
├── entities/
│ ├── _overview.md
│ └── {entity}.md
├── processes/
│ ├── _overview.md
│ └── {process}.md
└── glossary/
├── _overview.md
└── {term}.md
Example Dialogue
User: "Document the Order entity"
GOOD Response:
"I'll help document the Order entity. First some questions:
1. Which domain does Order belong to? (e.g., 'ecommerce', 'sales')
2. What attributes does an Order have?
3. What are the data types for each?
4. How does Order relate to other entities?
5. What states can an Order be in?
I'll only document what you tell me."
Remember
- Dialogue first, documentation second
- Verify, don't assume
- Mark unknowns with
# TODO:or# QUESTION: - Use Mermaid diagrams for visualization
- Keep files focused - one entity/process/term per file
Resources
- For detailed templates and examples, see domain-guide.md