Skip to main content
In this lesson we continue building an “ideal” development setup — a collection of tools and patterns you can adopt to make your environment consistent, secure, and productive. The ideal setup is the one that works for you; the suggestions here are practical defaults you can adapt. This article focuses on two complementary components:
  • Client rules — persistent, system-level guidance that the assistant will apply to every conversation and code generation task.
  • The Cline memory bank — a structured, persistent documentation system that preserves project context across sessions.

​
Client rules

Client rules let you encode project-level guidance that the assistant consults automatically. Use them for coding standards, security constraints (for example, “do not access repository X”), forbidden actions, network restrictions, or any team-wide policy you want enforced. You can create client rules via the product UI or with shortcuts like /new rule. If you prefer editing locally, manage rules inside your editor (for example, Visual Studio Code). Rules can be:
  • Global — apply to all projects for your account.
  • Workspace — apply to the current workspace.
  • Project-specific — apply only to the repository where they live.
Project-specific rules typically live under .client/rules/. For example, adding a file named Python-rules.md will create .client/rules/Python-rules.md, which the assistant will consult for that project.
Client rules are persistent and applied automatically. Use them to encode team conventions, forbidden actions (for example, “do not access repository X”), or project-wide safety constraints.

​
Example: Python coding rules

Below is a sample rules document you could add at .client/rules/Python-rules.md. Store it once and the assistant will consult it when generating or reviewing Python code for the project.
Once .client/rules/Python-rules.md exists, the assistant will follow these guidelines for Python-related requests in that repository.

​
Memory bank

The memory bank is a structured documentation system that turns the assistant from a stateless helper into a persistent development partner. It preserves project context across sessions, making the assistant more effective on long-lived or large codebases.
A screenshot of a dark-themed documentation webpage (docs.cline.bot) about the "Cline Memory Bank," showing left and right navigation sidebars and central content. The main text explains what the memory bank is and lists key benefits in bullet points.
The memory bank typically includes core markdown files that describe the project at multiple levels: high-level brief, product rationale, the current sprint, system patterns, progress, and known issues. See the official docs for more details: https://docs.cline.bot/prompting/client-memory-bank.
A dark-mode screenshot of a documentation webpage (docs.cline.bot) about the "Cline Memory Bank," showing a central flowchart diagram of markdown files. Left and right sidebars display navigation menus while the main content shows headings and bullet points explaining memory bank files.

​
Typical memory-bank files and purposes

A dark-themed browser screenshot of documentation titled "Memory Bank Files Explained," showing a three-column layout with a left navigation menu, a central content area listing core files (e.g., projectbrief.md, productContext.md, activeContext.md), and a right-side table of contents.

​
Creating and updating the memory bank

A simple workflow:
  1. Create a memory-bank/ folder at the project root and add the core markdown files listed above.
  2. Use the assistant’s “initialize memory bank” action to scaffold standard files automatically.
  3. As the project evolves, run the “update memory bank” action to push new or changed content into the memory bank so the assistant always reads the latest context.
  4. Allow the assistant to perform tasks while consulting the memory bank for more accurate, context-aware results.

​
Example scaffolding templates

Product Context (scaffold)
System Patterns (scaffold)
Progress (scaffold)
Core workflows (illustration)

​
Using Act mode to scaffold and update

When you enable the assistant to perform actions (for example, the “initialize memory bank” action), it can:
  • Generate scaffold files under memory-bank/.
  • Create or update the core markdown files.
  • Keep documentation synchronized with development changes as you push updates.
Run the “update memory bank” action whenever you make substantive changes so the assistant has the latest context for future tasks.
Do not store secrets (API keys, passwords, or private certificates) in the memory bank. Treat it as project documentation only. Use secure secret management for credentials.

​
Why this matters

A well-maintained memory bank plus explicit client rules give the assistant:
  • Clear policies and style preferences to apply automatically.
  • Project context that informs design, implementation, and reviews.
  • Reduced onboarding friction for new contributors.
  • Better consistency for refactors and long-lived work.
For long-term projects, backfill the memory bank with historical decisions and then iterate. This makes the assistant immediately useful across many kinds of tasks.
In short: combine client rules (policy and style) with a maintained memory bank (project context) to make the assistant a consistent, persistent development partner.

Watch Video