Accueil / Articles / Give Your Project an AI Memory With Markdown Files in the Repo

Cet article est publié en anglais.

Give Your Project an AI Memory With Markdown Files in the Repo

Create an .ai-memory folder with overview, architecture, schema, API and decision files so any coding assistant understands your codebase from the first prompt.

1365 mots

Sooner or later every developer who works with an AI assistant hits the same wall. You ask it to build authentication for your Next.js app and the answer is good. Then you say "now hook it into my existing user schema" and it acts as if it has never seen the project. It has no idea about:

  • your folder structure
  • your database schema
  • your coding standards
  • the feature decisions you made
  • why certain files exist
  • what you deliberately avoided

So you explain it all again, and again. At some point it becomes obvious that the model isn't the problem. Memory is.

The fix is cheap: keep a project memory in Markdown files inside the repo, so the assistant starts each session already knowing how the project works. It isn't tied to Anthropic's Claude. OpenAI models, Gemini and any other coding assistant can read the same files.

What project memory is

It's a persistent knowledge layer for your codebase. Chat history disappears, so you store structured project knowledge in the repository itself:

  • what the business does and why
  • how the system is built
  • which features shipped and when
  • how files relate to each other
  • coding conventions
  • the reasoning behind past decisions
  • API contracts
  • database schemas

In effect your repo becomes self-documenting in a form an AI can read. That matters because a model without context is guessing, and with context it gets a lot more useful.

Why bother

Think about what you'd hand a new senior engineer on day one: architecture docs, a setup guide, the folder layout, API docs, an explanation of the business logic, a roadmap, known issues, coding conventions. An AI needs the same material, and it can absorb it instantly.

Compare the prompts. Without memory you can only ask something generic like "explain my payment flow." With it you can ask "add retry logic to failed Razorpay webhooks, following our existing event architecture." One is vague and the other is precise.

The memory folder

Put a hidden folder in the repository root, next to your source directories:

/project-root
 ├── src
 ├── components
 ├── services
 ├── .ai-memory

And inside .ai-memory:

.ai-memory/
├── project-overview.md
├── architecture.md
├── folder-structure.md
├── database-schema.md
├── api-contracts.md
├── coding-guidelines.md
├── feature-history.md
├── active-tasks.md
├── known-issues.md
├── decision-log.md

It's simple, readable and version controlled. It plays the role of the project's brain. Each file has a job.

project-overview.md

This is the most important file. It says what the project does, who uses it, which problem it solves and what the core features are. For example:

# Project Overview

Project Name: DevResume AI
Purpose:
A SaaS platform where developers create digital resumes,
ATS-friendly resumes, and portfolio profiles.
Primary Users:
- Developers
- Students
- Recruiters
Core Features:
- Resume builder
- Portfolio generator
- Job tracker
- AI interview prep

Without it the AI only sees code. With it, it understands what the code is for, and that changes the quality of everything it suggests.

architecture.md

Describe how the app is put together:

# Architecture

Frontend:
- Next.js 16
- React 19
- Tailwind CSS
Backend:
- Node.js
- Express
Database:
- PostgreSQL
Authentication:
- NextAuth
Storage:
- AWS S3
Deployment:
- Vercel

This stops the AI from suggesting the wrong stack and saves a lot of corrections.

folder-structure.md

Teach the file relationships, with a short explanation beside each directory:

src/
 ├── app/
 ├── modules/
 ├── shared/
 ├── services/
 ├── hooks/

/modules = feature-based architecture
/shared = reusable UI
/services = API integrations
/hooks = custom hooks

The assistant then knows where new code belongs, and you stop getting random file placement.

database-schema.md

This one is gold:

User
- id
- name
- email
- role
Resume
- id
- userId
- templateId
- content
Portfolio
- id
- userId
- slug

With the schema on hand, the AI can write queries, migrations, joins and validations accurately.

api-contracts.md

Document your APIs:

POST /api/auth/login
Request:
{
 email: string
 password: string
}

Response:
{
 token: string
 user: object
}

The payoff is frontend code that's ready to integrate, based on real contracts and not assumptions.

feature-history.md

Track what has shipped:

# Feature History

v1.0
- Authentication
- Resume Builder
v1.1
- Portfolio Export
v1.2
- AI Resume Suggestions

That keeps the AI from rebuilding things you already have, which is a big and underrated win.

decision-log.md

Record why decisions were made:

Decision:
Used PostgreSQL instead of MongoDB.

Reason:
Need relational joins for resume templates.

Now the assistant won't propose an architecture you already rejected. This file alone can save hours.

Memory per feature

For finer detail, give each feature its own memory file:

/features/auth/auth.memory.md
/features/payments/payments.memory.md
/features/profile/profile.memory.md

A typical one looks like this:

# Auth Feature

Purpose:
Handles login/signup.
Flow:
Signup → Verify Email → Create Profile → Generate JWT
Files:
- auth.service.ts
- auth.controller.ts
- auth.routes.ts
Known edge cases:
- Duplicate emails
- Expired tokens

That gives very local context, close to component-level knowledge.

Prompts that build and maintain it

To bootstrap memory for a project that already exists, use this prompt:

Analyze my entire project and generate AI memory files.

Create:
1. project-overview.md
2. architecture.md
3. folder-structure.md
4. database-schema.md
5. api-contracts.md
6. feature-history.md
7. known-issues.md
8. coding-guidelines.md
9. decision-log.md
Rules:
- Read all folders
- Understand relationships
- Summarize clearly
- Keep markdown structured
- Mention business logic
- Mention important dependencies
- Mention reusable patterns

For one feature at a time, this prompt generates the feature file, and it scales well:

Analyze this feature folder and create featureName.memory.md.

Include:
- Feature purpose
- Business logic
- File roles
- API dependencies
- Database dependencies
- Edge cases
- Future improvements
- Current limitations

After new work lands, run an update prompt. It's critical, because stale memory is dangerous:

Update my AI memory files based on the new changes.

Check:
- New files
- Modified APIs
- Schema changes
- New feature flows
- New dependencies
- New business logic
Update only relevant markdown files.

Habits that keep it useful

  • Keep it light. Don't write novels, since models do better with clear, short text.
  • Version it with Git. Commit it, review it and let it evolve like code.
  • Update it after every major feature. The rule is simple: feature shipped, memory updated. No exceptions.
  • Stick to plain Markdown. It's universal, portable and readable anywhere.

It isn't limited to Claude

The same setup works with Claude Code, OpenAI Codex, GitHub Copilot, Cursor, Google Gemini CLI and Windsurf. The model isn't what makes it work. The memory is.

The point

Many developers treat AI like a chatbot. Teammates need context, and a plain .ai-memory folder is enough to turn repetitive prompting into real collaboration. Once the project has memory, the assistant stops behaving like an intern and starts behaving more like an architect. Expect this to become ordinary engineering practice within a couple of years, so it's worth starting now.