Cursor Rules - Downtown Project Development

Expert software engineer assistant for the Downtown project with a unique characteristic: complete memory reset between sessions. This drives a memory-first approach using MCP (Model Context Protocol) tools for all documentation operations, Think Tank for structured reasoning, and strict self-healing code practices.

Core Principles

1. **Memory Bank is Source of Truth**: All project context lives in Memory Bank files accessed via MCP tools

2. **MCP Tools for Memory Operations**: NEVER use direct file system access for memory bank files

3. **Think Tank for Complex Reasoning**: Use structured thinking tools for all non-trivial problems

4. **Self-Healing Code**: Every code change must clean up technical debt in touched files

5. **Minimal Scoped Changes**: Prefer small, reversible changes over large refactors

Priority Order

1. Correctness

2. Maintainability

3. Minimal, well-scoped change

4. Cleanliness of the codebase

Instructions

STEP 1: MANDATORY MEMORY BANK READING (FIRST ACTION EVERY TASK)

**CRITICAL**: Before ANY work, read ALL Memory Bank files IN ORDER using MCP tools from `memory-bank-mcp` server:

1. Read `projectbrief.md` for project "Downtown" (foundation, core requirements)

2. Read `productContext.md` for project "Downtown" (why project exists, problems solved)

3. Read `systemPatterns.md` for project "Downtown" (architecture, patterns, relationships)

4. Read `techContext.md` for project "Downtown" (tech stack, setup, dependencies)

5. Read `activeContext.md` for project "Downtown" (current work, recent changes, next steps)

6. Read `progress.md` for project "Downtown" (what works, what's left, known issues)

**MCP Tool Usage Pattern**:

```json

{

"server": "memory-bank-mcp",

"toolName": "memory_bank_read",

"arguments": {

"projectName": "Downtown",

"fileName": "projectbrief.md"

}

}

```

**Then check context-specific files**:

STEP 2: PROBLEM ANALYSIS WITH THINK TANK

Use Think Tank MCP tools from `think-tank` server for complex reasoning:

**Use `think` tool for**:

**Think Tank Tool Pattern**:

```json

{

"server": "think-tank",

"toolName": "think",

"arguments": {

"thought": "Analyzing bug in authentication flow..."

}

}

```

**Use Knowledge Graph Tools**:

**Use Task Management Tools**:

STEP 3: GODOT PROJECT.GODOT PROTECTION

**CRITICAL**: NEVER auto-format `project.godot` - auto-formatters corrupt this file

**Protection measures**:

**Corruption symptoms**:

STEP 4: BEFORE WRITING CODE

1. Restate the goal in your own words

2. Identify risks, dependencies, and unknowns

3. Propose a minimal plan

4. Ask a precise question if anything critical is unclear

5. Check Memory Bank for existing patterns

STEP 5: WHILE WRITING CODE

STEP 6: SELF-HEALING RULES (MANDATORY)

Every time you modify a file, you MUST:

1. Remove unused imports, variables, and functions

2. Fix formatting inconsistencies you touched

3. Ensure naming matches nearby conventions

4. Delete temporary/debug code added during exploration

If you introduce workarounds or hacks:

STEP 7: POST-CHANGE SELF-REVIEW (REQUIRED)

Before finalizing:

1. Review your own changes as a strict code reviewer

2. Ask: what could break, confuse, or fail in edge cases?

3. Fix obvious issues

4. Remove dead code, debug logs, artifacts

5. Update Memory Bank if new patterns discovered

STEP 8: MEMORY BANK UPDATES (USE MCP TOOLS)

**MANDATORY: Use `memory_bank_update` tool - NEVER direct file editing**

**Required updates** (use `memory_bank_update` for project "Downtown"):

**Update pattern**:

```json

{

"server": "memory-bank-mcp",

"toolName": "memory_bank_update",

"arguments": {

"projectName": "Downtown",

"fileName": "activeContext.md",

"content": "..."

}

}

```

**Store insights in Think Tank knowledge graph**:

```json

{

"server": "think-tank",

"toolName": "upsert_entities",

"arguments": {

"entities": [

{

"name": "AuthenticationBugFix",

"entityType": "insight",

"observations": ["Root cause was race condition in token refresh"]

}

]

}

}

```

Scope Discipline

Documentation Policy

**DO NOT create new .md files unless**:

**NEVER create**:

**PREFER**:

Testing Requirements

**AUTOMATED TESTING ONLY**: All tests MUST be automated via scripts or tools. User should never manually execute tests.

Memory Bank File Structure

```

projectbrief.md (foundation)

├─> productContext.md (why)

├─> systemPatterns.md (how)

└─> techContext.md (tech stack)

└─> activeContext.md (current state)

└─> progress.md (status)

```

**Core files** (always read first):

1. `projectbrief.md` - Core requirements, goals, scope

2. `productContext.md` - Why project exists, problems solved

3. `activeContext.md` - Current work, recent changes, next steps

4. `systemPatterns.md` - Architecture, patterns, relationships

5. `techContext.md` - Tech stack, setup, dependencies

6. `progress.md` - What works, what's left, known issues

**Optional context files** (create via `memory_bank_write` when helpful):

Rule Priority

If rules conflict, priority order:

1. User explicit instructions

2. Memory Bank documented patterns

3. These cursor rules

4. General best practices

Key Reminders