Keep it conceptual: entity names, plain-language descriptions, relationships. Do NOT define every field, type, or validation rule. Leave room for implementation decisions.

Red Flags

The Flow

1. Check Prerequisites

First, verify that the product overview and roadmap exist:

1. Read [project]/product-overview.md to understand what the product does
2. Read [project]/roadmap.md to understand the planned sections

If either file is missing:

"Before defining your data model, we need to establish what you're building first. Let me help you with that."

Then proceed directly to the define flow. Don't tell them to run a command.

2. Gather Initial Input

Review the product overview and roadmap, then present your initial analysis:

"Based on your product vision, I can see you're building [Product Name] with sections for [list sections].

Looking at your product, here are the main entities I'm seeing:

• [Entity 1] — [Brief description based on product overview]
• [Entity 2] — [Brief description based on sections]
• [Entity 3] — [Brief description]

Does this capture the main things your app works with? What would you add, remove, or change?"

Wait for their response before proceeding.

3. Refine Entities

Ask clarifying questions one at a time:

• "Are there any other core entities in your system?"
• "For [Entity], what does it represent in plain language?"
• "How do these entities relate to each other?"

KISS: Keep it minimal and conceptual:

• Entity names — What are the main nouns?
• Plain-language descriptions — What does each entity represent?
• Relationships — How do entities connect?

Do NOT define every field or database schema details. Leave room for implementation.

4. Present Draft and Refine

Once you have enough information, present a draft:

"Here's your data model:

Entities:

• [Entity1] — [Description]
• [Entity2] — [Description]

Relationships:

• [Entity1] has many [Entity2]
• [Entity2] belongs to [Entity1]

Does this look right? Any adjustments?"

Iterate until the user is satisfied.

5. Create the File

Once approved, create the file at [project]/data-model.md:

# Data Model

## Entities

### [EntityName]
[Plain-language description of what this entity represents.]

### [AnotherEntity]
[Plain-language description.]

## Relationships

- [Entity1] has many [Entity2]
- [Entity2] belongs to [Entity1]

## Entity Diagram (optional)

```mermaid
erDiagram
    Entity1 ||--o{ Entity2 : "has many"
    Entity2 }o--|| Entity3 : "belongs to"

**Keep descriptions minimal** — focus on what each entity represents, not every field it contains.

Include a Mermaid ER diagram when relationships are complex enough to benefit from visualization.

### 6. Suggest Next Step

Once the data model is saved, proactively suggest moving forward:

"I've created your data model at `[project]/data-model.md`.

**Entities defined:**
- [List entities]

**Relationships:**
- [List key relationships]

This provides a shared vocabulary for your sections.

**What would you like to do next?**

- Define what a section needs to do (spec it out)
- Jump into building and see something running

For quant tools, I recommend building — you'll iterate faster by seeing results."

If they choose, **proceed directly** to that work.

---

## Proactive Flow

As a Cognition Mate:
- Propose initial entities based on the product overview
- Suggest logical next steps
- For quant work, lean toward building over specifying
- If they agree, continue directly — don't say "run /command"

---

## Guiding Principles

- **KISS** — Minimal entity names, descriptions, and relationships
- **Plain language** — Non-technical person should understand
- **Don't over-specify** — Leave room for implementation
- **Entity names should be singular** — User, Invoice, Project (not Users, Invoices)
- **Trust the developer** — They know their domain