Stop making your AI coding engine to re-scan 50,000 lines of code every single time you make an update which it then forgets.

If you want AI to perform like the best Senior Coder, then you need to force it to have a Self-Updating Memory System.

Trick your AI to continuously read, update, and maintain 5 hyper-focused Markdown files in your project root that act as its persistent memory / brain.

💡 Why this workflow separates pros from amateurs:

⚡ Instant context retrieval: The AI scans root state files in <1 second instead of parsing thousands of lines.

🛡️ Zero regressions: roadmap.md forces the AI to check safety boundaries before touching existing logic.

🔒 No schema hallucinations: schema.md keeps database queries and type contracts completely locked in.

Copy-paste this exact instruction block directly into your AI engine's rules section or root memory files
(e.g., .cursor/rules, .windsurfrules, AGENTS.md for OpenAI/Codex, CLAUDE.md for Claude, .github/copilot-instructions.md for Copilot, or custom system settings in Replit, Bolt, Lovable, etc.):

Prompt here

# AI Context & Repository State Maintenance Rules

You are working on a large, highly complex application. To maintain absolute context, prevent regression bugs, and eliminate the need to scan the entire repository for every request, you MUST proactively maintain and read the following five hyper-focused Markdown files in the project root:
- system-architecture.md
- schema.md
- state-management.md
- roadmap.md
- prd.md

Before writing ANY code for a change or feature, read these files. After implementing ANY modification, immediately update the relevant files. Keep descriptions short, punchy, and structured via bullet points.

## Context Density Guidelines
• Max 3 bullet points per subsection. Every bullet must contain a concrete technical identifier, type, or constraint.
• Structural Signatures Only: Use types, schemas, and endpoint signatures instead of explanatory paragraphs.
• Zero Implementation Prose: Reference source file paths and export names instead of step-by-step logic.

## File Specifications

1. system-architecture.md (Stack, Core Engines & Optimization)
• Core Stack: Frontend framework, backend infrastructure, database configuration, hosting.
• Heavy Engines: Document setups for heavy sub-systems via source paths (e.g., real-time engines, custom rendering, worker threads).
• Performance Budgets: List critical optimization limits (memory ceilings, asset budgets, throttling).
• Third-Party Integrations: Core API services, authentication providers, external webhooks.

2. schema.md (Data Models & Analytical Constants)
• Persistent Storage: Database tables, column names, strict TypeScript/SQL types, foreign keys.
• Complex Local State Shapes: Core payload definitions or interface signatures.
• Logical/Math Constants: Immutable formulas and core business logic coefficients.

3. state-management.md (Dynamic Flows & Module Registry)
• Global & Shared Stores: State management slices mapped via store paths and core actions.
• Network & Sync State: Event-driven syncing logic or real-time replication.
• Module Registry: Index mapping unique sub-modules, paths, dependencies, and boundaries.

4. roadmap.md (Task Sequencing & Regression Prevention)
• Strict Sprint Columns: Backlog, In Progress, and Completed.
• Micro-Tasks: Feature breakdown into tiny, testable bullet points with target file paths.
• Regression Prevention: Bulleted list of critical paths not to break during the sprint.

5. prd.md (Product Requirements & Feature Specifications)
• Core Value Proposition: One-sentence definition of primary utility and target user.
• User Stories & Epics: Formatted as `As a [persona], I want [capability] so that [benefit]`.
• Acceptance Criteria: Clear, testable pass/fail conditions for features.
• Out of Scope: Explicit boundaries defining what the product intentionally will NOT support.