How to Use Cline Rules and Custom Instructions

US monthly search volume for the phrase "cline rules" sits at about 260 queries, according to DataForSEO keyword data pulled for this article. That demand is modest, but the gap in existing coverage is larger than the number suggests. Many posts still treat rules, skills, memory banks, and system prompts as interchangeable customization knobs. Official Cline documentation does not. Rules have a dedicated customization page as a first-class surface for persistent coding standards and project instructions.

Quotable definition: Cline Rules are project-level instruction files that inject persistent coding standards and workflow guidance into Cline before each interaction.

In practice, rules are markdown (or plain text) files that Cline loads as context so you stop retyping the same preferences every task. Official docs list the jobs rules are built for:

• Team coding standards (naming, file layout, error handling)
• Project-specific context (stack, architecture decisions, dependencies)
• Consistent documentation or testing requirements
• Hard constraints such as "do not modify /legacy" or "always use TypeScript"

That is different from a one-off system prompt pasted into chat. A pasted prompt dies when the thread ends. Rules live on disk, can be toggled, can be scoped to file paths, and can ship with the repo so every teammate gets the same agent contract.

Cline also reads rule formats from adjacent tools, which matters if you already invested elsewhere. Official docs list these supported sources:

Detected rule types appear in the Rules panel, where you can toggle each one. You do not have to rewrite every legacy file on day one, but long term most teams consolidate into .clinerules/ so governance lives in one place.

The rest of this guide is the sequence most teams need: create rules, choose workspace vs global scope, add path conditionals, verify injection, then combine with skills and ignore files so the agent stays sharp without burning context.

Official Cline docs put rules in two places, and the choice is a governance decision, not a cosmetic one.

Workspace rules live in .clinerules/ at the project root. Use them for team standards, project constraints, and anything you want collaborators to inherit through version control. Cline processes all .md and .txt files in that directory and merges them into one rule set. Numeric prefixes such as 01-coding.md are optional organization helpers, not a required schema.

A typical layout looks like this:

your-project/
├── .clinerules/
│   ├── coding.md
│   ├── testing.md
│   └── architecture.md
├── src/
└── ...

Global rules live in the system Cline Rules directory and apply across projects. Official default locations:

Cline also reads cross-tool global AGENTS instructions from ~/.agents/AGENTS.md.

When workspace and global rules both exist, Cline combines them. Workspace rules take precedence on conflict. That precedence is the team-friendly default: personal style can live globally, project law lives in the repo and wins when the two disagree.

What belongs where Put personal preferences in global rules: editor habits, preferred explanation depth, languages you always want comments in. Put shared constraints in workspace rules: module boundaries, test policy, forbidden directories, API client patterns, monorepo package conventions.

A useful split for a mid-size TypeScript monorepo:

• Global: "Prefer small diffs. Ask before large refactors."
• Workspace coding.md: naming, import rules, error types
• Workspace architecture.md: package boundaries, dependency direction
• Workspace testing.md: required coverage for business logic and API routes

Multi-root workspaces

Official multi-root docs add one hard limit: .clinerules/ only applies from the primary workspace folder (the first folder in the multi-root set). Rules in secondary folders are ignored. Workarounds from the docs: put shared rules in the primary folder, or use global rules so they apply everywhere.

If your team works in multi-root setups often, document that primary-folder rule in the README. Otherwise someone will drop .clinerules/ in a secondary package and wonder why nothing changes.

Official docs give a short creation path. The quality work is in how you write and prove the rules.

Create a rule file

1. Open the Rules menu (scale icon at the bottom of the Cline panel, left of the model selector).
2. Click "New rule file..." and name it (for example coding-standards). Cline creates a .md file.
3. Write focused markdown. One concern per file so you can toggle topics independently.

You can also use the /newrule slash command to have Cline draft a rule interactively, then edit the result like any other source file.

Every rule has a toggle. Disable a strict testing rule while prototyping, or enable a client-specific rule only when that client's branch is active. Toggles avoid delete-and-recreate churn.

Write rules Cline can follow

Official guidance is blunt: be specific, include the why, point at real files, keep rules current, and keep one concern per file. Vague lines such as "use good names" waste context. Concrete lines such as "camelCase variables, PascalCase classes, UPPER_SNAKE constants" give the model a checkable contract.

A structure that works well:

### Project Guidelines

### Code Style
- Use TypeScript for all new files
- Prefer composition over inheritance
- Follow error handling in /src/utils/errors.ts

### Testing
- Unit tests for business logic
- Integration tests for API endpoints

Rules consume context tokens. Official docs warn against pasting entire style guides. Keep rules short and link out when the full reference is long.

Conditional rules with path frontmatter

Without conditionals, every rule loads on every request. With conditionals, rules activate only when current context matches their paths. Official docs describe this as the difference between handing someone a full policy manual and the one page they need.

Add YAML frontmatter at the top of a rule in .clinerules/:

---
paths:
  - "src/components/**"
  - "src/hooks/**"
---

### React Component Guidelines

- Use functional components with hooks
- Extract reusable logic into custom hooks
- Keep components focused on one responsibility

Currently supported conditional field is paths, an array of globs. Useful syntax from the docs:

• * matches within a path segment
• ** matches recursively
• ? matches one character
• {a,b} matches either pattern

Behavior details that trip people up:

• Multiple patterns: the rule activates if any pattern matches any file in context
• No frontmatter: rule is always active
• paths: []: rule never activates (temporary soft-disable)
• Invalid YAML: Cline fails open and activates the rule with raw content visible for debugging

"Current context" for matching includes your message text, open tabs, visible files, files Cline edited in the task, and pending edits. Mention paths explicitly in prompts (update src/services/user.ts) so path rules fire reliably. Vague language ("update the user service") may not.

When a conditional rule activates, Cline shows a notification such as "Conditional rules applied: workspace:frontend-rules.md". That notification is your first verification signal.

Verify injection Treat verification as a short checklist, not a vibe check:

1. Confirm the file sits under .clinerules/ (or the expected global path) and is toggled on.
2. For conditionals, open or mention a matching file and watch for the activation notification.
3. Ask Cline a targeted question that only a loaded rule would answer correctly (for example, "which error helper should new services use?").
4. If the answer ignores the rule, check multi-root primary folder, toggles, YAML delimiters, and whether a conflicting global rule is also active.
5. For temporary tests, add a loud TEST: this rule is active line, confirm activation, then remove it.

Combine with skills and ignore files

Rules are not the whole customization stack. Official skills docs draw a clean line: rules stay active (or path-conditional), while skills load on demand. Skills package task-specific procedures in a SKILL.md directory, with progressive loading so only metadata (100 tokens per skill) sits in context until a skill triggers. Skills live under .cline/skills/ (workspace) or `/.cline/skills/` (global), and can be invoked with slash commands.

Use rules for always-on policy. Use skills for heavy procedures such as deploy runbooks, release-note generation, or data analysis recipes that should not tax every chat.

Pair both with .clineignore. Official ignore docs state that without exclusions Cline may load huge trees of dependencies and build output into context, and that a good .clineignore can cut starting context from 200k+ tokens to under 50k. The file uses gitignore-style patterns, sits at the project root, and blocks automatic listing, context gathering, and search, while still allowing explicit @ mentions of ignored paths when you need them.

A practical stack for a Node monorepo:

• .clineignore: node_modules/, dist/, coverage, secrets, large fixtures
• Always-on rules: TypeScript standards, security constraints, PR expectations
• Path rules: frontend vs backend vs tests
• Skills: deploy, migration, changelog

That combination is the featured-snippet sequence: create rules, scope them, verify injection, then combine with skills and ignore files.

Keep Cline outputs in one shared workspace

Store agent-produced files where humans and agents share version history, search, and MCP access. Start a 14-day free trial and connect your coding workflow through Fast.io's MCP endpoints.

Start 14-Day Trial

Search results often mash these terms together. Keeping the boundaries straight saves weeks of confused configuration.

Rules vs custom instructions / system prompts

In Cline's product language, rules are the durable, file-backed instruction layer with a UI, toggles, workspace and global storage, and optional path conditions. "Custom instructions" in casual conversation usually means the same job (tell the agent how to behave), but the durable mechanism is rules, not a disposable chat preface.

If someone asks "where do I put my Cline system prompt," the answer that survives a reboot is: a markdown file under .clinerules/ (team) or the global Rules directory (personal). Chat-only instructions are fine for a one-shot experiment. They are a weak foundation for team standards.

Rules vs skills

Official skills docs state the contrast directly: skills are modular instruction sets that extend Cline for specific tasks and load only when relevant. Rules apply as standing guidance. Skills use progressive loading (metadata always, body on trigger, resources as needed). Rules without frontmatter are always candidates for every request; conditional rules narrow that set by path.

Decision heuristic:

• If the guidance should shape almost every edit, it is a rule.
• If the guidance is a multi-step procedure for a named job, it is a skill.
• If the guidance is path-local style (React components, SQL models), prefer a conditional rule first; promote to a skill only when the procedure gets long or needs scripts and templates.

Rules vs memory bank patterns

Community "memory bank" setups store project state in markdown files the agent reads and updates across sessions (brief, active context, progress, patterns). That is state persistence. Rules are behavior contracts. You can use both: rules tell Cline to read and update the memory bank; the bank holds evolving project facts. Do not dump the entire bank into a rule file. That bloats context and fights the point of a living state directory.

Team governance patterns

Once rules live in git, treat them like production code:

1. Review rules in pull requests. A bad rule can push every agent run toward the wrong pattern.
2. Own a small set of always-on files. Everything else should be path-conditional or a skill.
3. Version and changelog material changes. "We now require repository-layer data access" is a team event, not a silent personal edit.
4. Separate org policy from repo policy when needed. Org-wide security constraints can live in a shared template repo or global rule distribution process; product-specific architecture stays in the product repo's .clinerules/.
5. Document the primary multi-root folder so secondary packages do not accumulate dead rule directories.

For artifacts that leave a single laptop (generated reports, client deliverables, agent-produced patches packaged for review), local disk and git still matter, but they are not always enough. Object storage such as S3 and consumer drives like Google Drive can hold files, yet agents and humans rarely share the same permissioned, versioned, searchable surface. Fast.io is an intelligent workspace option for that handoff layer: org-owned workspaces, per-file version history, Intelligence Mode for semantic search and citation-backed chat, and MCP access over Streamable HTTP at /mcp (legacy SSE at /sse) so Cline can read and write shared project outputs through consolidated MCP tools. Start from storage for agents and the Fast.io AI product page when you wire remote storage into an MCP-capable coding agent. For transport details, see the MCP guide linked from that setup path.

Copy these patterns and adapt the paths to your tree. Keep files short enough that a human can review them in a few minutes.

Always-on project contract

### Engineering Contract

### Non-negotiables
- Do not commit secrets or edit .env files
- Do not modify /legacy without explicit approval
- Prefer small, reviewable diffs over broad rewrites

### Defaults
- TypeScript for new application code
- Repository pattern for data access
- Match existing error types in /src/utils/errors.ts

Frontend path pack

---
paths:
  - "src/components/**"
  - "src/pages/**"
  - "src/hooks/**"
---

### Frontend Guidelines
- Prefer server components when possible
- Keep client components small
- Colocate tests next to components when the repo already does so

Backend path pack

---
paths:
  - "src/api/**"
  - "src/services/**"
  - "src/db/**"
---

### Backend Guidelines
- Dependency injection for services
- Database access only through repositories
- Return typed errors instead of bare throws

Test path pack

---
paths:
  - "**/*.test.ts"
  - "**/*.spec.ts"
  - "**/__tests__/**"
---

### Testing Standards
- Name tests "should [behavior] when [condition]"
- Mock external systems, not internal modules
- Prefer factories over brittle fixtures

Starter .clineignore

node_modules/
**/node_modules/
/build/
/dist/
/out/
/coverage/
.env
.env.*
*.min.js
*.map

Adjust data-file and lock-file exclusions for your stack. Official ignore docs note that .clineignore is separate from .gitignore: git-tracked fixtures can still be irrelevant to the agent and belong in ignore.

Troubleshooting matrix

Rule never seems to apply

• File not under .clinerules/ or global Rules path
• Toggle off in the Rules panel
• Multi-root: rules only in secondary folders
• Conditional paths do not match open or mentioned files
• Broken YAML frontmatter (check --- delimiters and indentation)

Rule applies when it should not

• Over-broad ** patterns
• Open tabs matching the glob even when you think you are "in" another area
• Paths mentioned in the prompt count as context

Context still huge after adding rules

• Rules add text; they do not shrink the repo tree. Add or tighten .clineignore
• Move long procedures into skills so they load on demand
• Split always-on files; promote specialty guidance to path rules

Team members get different agent behavior

• Global personal rules overriding expectations (remember workspace wins on conflict, but non-conflicting globals still merge in)
• Uncommitted local rule edits
• Skills installed globally on one machine only

Where Fast.io fits after the code lands

Cline rules govern how the agent edits the local project. They do not, by themselves, create a durable team vault for outputs, client packages, or cross-machine agent runs. Keep source of truth in git. For shared, permissioned delivery of agent-produced files, a workspace with version history and MCP access is the coordination layer. Fast.io plans start with a 14-day free trial (credit card required): Starter at $29/mo, Business at $99/mo, Growth at $299/mo. Pair Cline's local rule stack with a shared workspace when humans need to review, search, and hand off agent work without emailing zip files.