🧠 AI Development, Part 4: Teaching Cursor to Think — Memory Banks & Rule Files

"Cursor is smart, but it doesn’t know your architecture — until you teach it."

In the last post, we introduced RIPER — a structured way to guide Cursor through the development process. But RIPER is more than just a philosophy. Behind the scenes, there’s infrastructure powering it: files that define behavior, store knowledge, and keep context consistent.

This post will unpack what’s inside the .cursor/ folder, and how it turns Cursor from an autocomplete bot into a repeatable system-aware teammate.

🧩 What Makes Cursor “Know” Your Project?

When you work with Cursor, it builds a folder called:

arduinoCopyEdit.cursor/

1. Rule Files – Define how Cursor behaves in each RIPER mode
2. Memory Bank – A structured, editable knowledge base of your project

🧠 Part 1: Rule Files – Giving Cursor a Brain

“Think of these like your AI teammate’s job description.”

Rule files are written in a Markdown-like language called .mdc (Markdown Cursor). They instruct Cursor how to behave in each development phase.

📁 Key Files in .cursor/rules/:

• core.mdc – Base logic for all interactions
• state.mdc – Tracks which RIPER mode you’re currently in
• start-phase.mdc – How to onboard Cursor to your project
• riper-workflow.mdc – Defines behavior per mode (e.g. “don’t write code during research”)
• customization.mdc – Your tweaks: verbosity, coding style, extra context

These files enforce discipline. For example:

// riper-workflow.mdc
If mode === "RESEARCH" {
  - Do not modify code.
  - Ask clarifying questions before making assumptions.
}

This keeps Cursor from jumping ahead or acting unpredictably. It also means that when someone on the team says “We’re in plan mode,” the AI understands what that entails.

📚 Part 2: Memory Bank – Teaching Cursor Your System

“This is where you store your team’s internal brain.”

The Memory Bank is a collection of human-readable Markdown files that store persistent knowledge across sessions.

📁 Key Files in the Memory Bank:

• projectbrief.md – The project’s goals and scope
• techContext.md – Tech stack choices + why
• systemPatterns.md – Architecture, services, naming conventions
• activeContext.md – Current focus of work
• progress.md – What’s been done so far

These files are part of the repo — not hidden away — which means they:

• Are visible in pull requests
• Can be reviewed just like code
• Can be updated after review sessions

🧠 Real Example: Teaching Cursor About Microservices

"Cursor now knows that our 'user-management' service is actually focused on login security."

We created custom memory files for each microservice. For example:

memory-bank/
  ├── microservices/
  │   ├── matching.md
  │   ├── coaches.md
  │   └── user-management.md

Each file includes:

• Purpose and boundaries
• Legacy decisions
• Known edge cases
• Planned changes

Cursor can reference these during research, innovation, and planning — making it smarter with every interaction.

⚠️ Important: Memory Isn’t Magic

Memory Bank files don’t automatically get injected into every chat. You need to either:

• Reference them manually in your prompt (@microservices/coaches)
• Mention them in your PRD, story, or /plan input
• Design your brief to tell Cursor which files to consider

We’re improving this by cross-linking files. For example:

// In projectbrief.md
For E2E testing best practices, see @memory-bank/testing/e2e-guide.md

👥 What About Multiple Developers?

"How do we deal with different progress states?"

This was a challenge.

The progress.md file tracks what Cursor has done so far. But what if Neil is working on telemetry and Romario is planning an E2E test?

Our solution:

• Use global memory for system knowledge
• Use scoped progress tracking for specific features
• Optionally commit individual progress to share ownership (e.g. during vacation handoff)

We’re still evolving this model — it may become a multi-user memory system later.

✅ TL;DR — What to Know

• Rule files shape how Cursor behaves in each RIPER mode
• Memory Bank files are your team’s shared brain — editable, reviewable, and permanent
• Cursor doesn’t know anything unless you teach it
• Use @-mentions and planning docs to bring memory into the chat

Next Up: Real-World Examples of Cursor + RIPER in Action

In the next post, we’ll show how we used Cursor and RIPER to:

• Add telemetry across microservices
• Refactor Angular Material imports
• Improve error reporting in our test framework

Spoiler: The AI wrote the PRs — and the QA test checklists — with almost no manual effort.

Until then, take a look at your project.
What would Cursor need to know before it can be trusted?

🧪 AI Development, Part 5: RIPER in Action — Real Examples from Production

“When you do it right, Cursor does the right work.” So far in this series, we’ve covered the theory: * Why AI development is now viable * How Cursor works as an IDE * What RIPER brings to the table * How memory banks and rule files give structure But none of that

Behind the BitNeil Kalman