| name | project-domain |
| description | Capture subject matter expertise and domain knowledge that will inform all product decisions - the ubiquitous language, domain rules, and principles from the field |
| disable-model-invocation | false |
description: Capture subject matter expertise and domain knowledge that will inform all product decisions - the ubiquitous language, domain rules, and principles from the field.
The user input to you can be provided directly by the agent or as a command argument - you MUST consider it before proceeding with the prompt (if not empty).
User input:
$ARGUMENTS
Create or update the domain model that captures subject matter expertise for this project.
Why Domain Knowledge Matters
Many products operate in specialized domains (fitness, healthcare, finance, education, etc.) where:
- Terminology matters: Using wrong terms confuses users and violates industry norms
- Domain rules exist: Physical, scientific, or regulatory constraints that can't be ignored
- Expertise is required: Decisions must be informed by domain knowledge, not guesses
- User trust depends on accuracy: Getting domain details wrong destroys credibility
This command captures that knowledge early so it informs all downstream decisions.
Project Identification
First, determine the project:
- Parse arguments for project identifier
- If not provided, ask: "Which project should I create/update domain model for?"
- List available projects in
specs/projects/
Set PROJECT_DIR = specs/projects/[PROJECT_ID]
Context Loading
Load existing project artifacts:
REQUIRED:
- {PROJECT_DIR}/project.md → Project vision, domain type, users
OPTIONAL (if exist):
- {PROJECT_DIR}/domain-model.md → Existing domain model (update mode)
- {PROJECT_DIR}/project-import.md → Brownfield import notes
- {PROJECT_DIR}/project-landscape-overview.md → Brownfield code scan
Detect mode:
- If
domain-model.md exists: UPDATE mode - enhance existing model
- If not: CREATE mode - build from scratch
Just-In-Time Research
Reference: Follow the just-in-time research pattern (.cursor/skills/just-in-time-research/SKILL.md)
Research Strategy
For domain model creation, research is critical. Identify knowledge gaps and conduct research:
1. Domain Terminology:
- Decision: What are the canonical terms in [domain]?
- Web Search: "[domain] glossary", "[domain] terminology standards"
- Deep Research (if specialized): Industry-specific ontologies, taxonomies
2. Domain Principles:
- Decision: What scientific/industry principles govern [domain]?
- Web Search: "[domain] best practices", "[domain] principles", "[field] science"
- Deep Research (if needed): Academic research, industry standards
3. Domain Rules & Constraints:
- Decision: What rules must always hold true in [domain]?
- Web Search: "[domain] safety guidelines", "[domain] regulations"
- Deep Research (if safety-critical): Regulatory requirements, certification standards
4. Domain Entities:
- Decision: What are the core concepts/entities in [domain]?
- Web Search: "[domain] data model", "[domain] ontology"
- Context7 (if applicable): Domain-specific libraries with established models
Research Execution
Use available MCP tools in this priority order:
- Perplexity MCP (preferred):
perplexity_search, perplexity_ask, perplexity_research
- Web Search (fallback):
web_search tool
- User Input: Ask user for SME knowledge they have
Embed all findings directly into the domain model sections with source citations.
Interactive Domain Elicitation
Step 1: Domain Identification
Ask the user:
"Let's capture the domain expertise for your project. I'll ask you questions to understand the specialized knowledge that should inform this product.
What domain/field does this product operate in?
(e.g., Exercise Science, Healthcare, Financial Services, Education, Agriculture, etc.)
What makes this domain specialized? Why does someone need expertise to build this correctly?"
Wait for response. Use the domain identification to guide research.
Step 2: Terminology Elicitation
"Now let's establish the canonical terminology for this domain.
What are the most important terms/concepts users and the product must use?
For each term, provide:
- The precise definition
- Any synonyms we should AVOID (to maintain consistency)
I'll also research standard terminology in [domain] to ensure we're aligned with industry norms."
Conduct terminology research and merge with user input.
Step 3: Core Concepts & Entities
"What are the core concepts or entities in this domain?
Think about:
- What 'things' does the user work with? (e.g., Workouts, Exercises, Muscle Groups)
- How do these relate to each other?
- What attributes define each concept?
I'll help structure these into a domain model."
Build entity definitions and relationships.
Step 4: Domain Rules & Invariants
"What rules must always be true in this domain?
Examples:
- 'A workout cannot have zero exercises'
- 'Rest periods must be positive numbers'
- 'A muscle group cannot be trained on consecutive days' (if that's a principle you follow)
These become validation rules and system invariants."
Step 5: Domain Principles
"What scientific or industry principles should guide this product?
For a fitness app, this might include:
- Progressive overload principle
- Muscle recovery requirements
- Volume-intensity relationship
For each principle, I'll research the evidence base and document how it applies to our product."
Conduct principle research and document with sources.
Step 6: Constraints & Safety
"What is impossible, unsafe, or inadvisable in this domain?
- Physical constraints (can't do negative reps)
- Safety constraints (max heart rate limits)
- Regulatory constraints (medical advice disclaimers)
These become hard boundaries the product must respect."
Domain Model Generation
After elicitation and research, generate {PROJECT_DIR}/domain-model.md using:
- Template:
.speck/templates/project/domain-model-template.md
- User-provided domain expertise
- Research findings with citations
- Structured entity relationships
Quality Checks
Before finalizing, verify:
Completeness:
Consistency:
Actionability:
Output
Create/update: {PROJECT_DIR}/domain-model.md
Summary to user:
✅ Domain model created/updated for [PROJECT_NAME]
Captured:
- [X] terms in glossary
- [X] core entities with relationships
- [X] domain invariants
- [X] foundational principles
- [X] constraints
Research sources:
- [List key sources used]
This domain model will be referenced by:
- /project-plan (epic structure informed by domain)
- /epic-specify (feature scope uses domain terms)
- /story-specify (user stories use glossary)
- /story-plan (data model validates against domain)
- /story-validate (checks domain invariants)
Next steps:
1. Review domain-model.md for accuracy
2. Add any missing domain expertise
3. Continue with /project-context or /project-plan
Integration Notes
For brownfield projects:
- Extract domain terminology from existing codebase (variable names, comments, UI text)
- Identify implicit domain rules in existing validation logic
- Document the "as-is" domain model before proposing changes
For recipe-based projects:
- Some recipes may have domain considerations (e.g., SaaS billing → subscription domain)
- Layer product-specific domain on top of recipe patterns
When to Run This Command
Recommended position in flow:
/project-specify → /project-clarify → /project-domain → /project-context → /project-architecture → /project-plan
Why here?
- After specify/clarify: We know what we're building
- Before context: Domain constraints inform technical constraints
- Before architecture: Domain entities inform data architecture
- Before plan: Domain structure informs epic organization
Can skip if:
- Product has no specialized domain (generic CRUD app)
- Domain is purely technical (developer tools)
- Team already has domain documented elsewhere (link to it)
