Session #3:

the "brain" architecture

30 - 45 minutes | Understanding "context" structure

What We're Doing

You're not writing the brain today - you're understanding how it's architected.

We've prepared a complete set of context files for the 4-player Simon game.

Your job:

1. Understand what each part of the brain does
2. See how the parts connect
3. Copy the brain into your project
4. Be ready to direct Cursor using it

The Brain Concept

Traditional Development:

• Intelligence lives in developer's head
• Gets lost, forgotten, or miscommunicated
• Every handoff drops context

Context-Driven Development:

• Intelligence lives in files (the "brain")
• Never forgets
• AI reads it perfectly every time

The .cursorrules folder = The Brain

The Brain Structure

What's inside:

A folder called .cursorrules containing multiple markdown files.

Each file handles a different aspect of the product:

• Product requirements
• Design constraints
• Technical architecture
• Quality rules
• Domain-specific logic

Together, they form the complete specification.

How the Brain Works

When you prompt Cursor:

What happens:

1. Cursor reads the product file
2. Sees the exact requirements you defined
3. Builds accordingly
4. No guessing, no forgetting

The brain is persistent memory.

Brain Walkthrough

We're going to walk through each file:

• What it contains
• Why it exists
• How Cursor uses it
• How it connects to other files

Follow along - we'll explain each part.

[File 1] Product Context

File: .cursorrules-product.md

What's in it:

• Target users (who plays)
• Zero-friction requirements (no passwords, WhatsApp links)
• User journey (join → lobby → game → result)
• Success metrics

Why it exists:

• Defines the "why" - the product vision
• Prevents Cursor from building unnecessary features
• Ensures user experience is intentional

Example rule: "Players join via shareable link - no login system, no passwords"

Result: Cursor will never build a login form

[File 2] Design Context

File: .cursorrules-mobile-ui.md

What's in it:

• Screen size baseline (iPhone SE: 375px × 667px)
• Layout calculations (button sizes, grid math)
• Color palette
• Spacing rules

Why it exists:

• Defines the "look" - visual constraints
• Ensures mobile-first design
• Provides exact measurements, not guesses

Example rule: "4 buttons in 2×2 grid: Each button = 160px × 160px with 8px gap"

Result: Cursor knows exact pixel values

[File 3] Architecture Context

File: .cursorrules-architecture.md

What's in it:

• Tech stack (React, Node, Socket.io)
• Project structure (folders, file organization)
• State management approach
• Deployment targets (Render)

Why it exists:

• Defines the "how" - technical decisions
• Ensures consistency across features
• Prevents Cursor from changing tech mid-project

Example rule: "Use Socket.io for real-time multiplayer sync, not polling"

Result: Cursor always uses WebSockets

[File 4] Quality Rules (TDD)

File: .cursorrules-tdd.md

What's in it:

• Test-first mandate
• Red-Green-Refactor cycle
• Bug fix process (test → fix → verify)
• No exceptions

Why it exists:

• Enforces quality automatically
• Prevents Cursor from skipping tests
• Creates documentation through tests

Example rule: "You MUST write a failing test before any code. No exceptions."

Result: Cursor refuses to code without tests

[File 5+] Domain-Specific Files

Examples:

• .cursorrules-game-logic.md (Simon game rules)
• .cursorrules-realtime.md (multiplayer sync)
• [Other files depending on scope]

What's in them:

• Specific to this project
• Game mechanics, business rules
• Technical patterns for this domain

Why they exist:

• Capture domain knowledge
• Prevent re-explaining the same concepts
• Enable precision in complex areas

How Files Connect

The brain is interconnected:

Product file says: "Players join with nicknames" → UI file specifies: "Nickname input: 2-12 characters" → Game logic validates: "Check length before joining lobby" → TDD file enforces: "Test this validation first"

Each file reinforces the others.

Cursor reads across files to build coherently.

Copying the Brain

Now let's set up your project:

Step 1: Create the folder In your project, create a folder called .cursorrules

Step 2: Copy the files From the shared directory, copy all the .cursorrules files into your folder

Step 3: Verify Ask Cursor: "What context files do you see in .cursorrules?"

You should see the complete list.

The Brain is Complete

What you now have:

✅ Complete product specification
✅ Exact design constraints
✅ Technical architecture defined
✅ Quality rules enforced
✅ Game logic documented

What you DON'T have:

• Still zero lines of code
• No features built yet

But Cursor now knows exactly what to build.

After Lunch: Execution

Next session:

• You'll direct Cursor to build features
• Using pointer prompts that reference these files
• Watching it follow the brain perfectly
• Building in 5-15 minutes what takes 30-60 traditionally

The brain does the remembering.
You do the directing.
Cursor does the building.

Questions?

Before lunch, any questions about:

• The brain structure?
• How files work together?
• What's in each file?
• How you'll use this in the afternoon?