How to Configure System Prompt Engineering and Rules in Cline

According to the SWE-bench leaderboard, top agentic coding systems evolved from resolving under 15% of real-world GitHub issues in early 2024 to achieving success rates above 90% on the SWE-bench Verified dataset in 2026. This performance improvement is not just a result of larger foundation models. It is driven by structured agentic frameworks that combine iterative tool access with system prompt engineering. In Cline, this system prompt engineering is achieved through the rules engine, which replaced the legacy custom instructions setting in version 3.18+.

In earlier versions of the extension, developers managed custom instructions using a single text box in the client settings interface. This approach quickly showed its limitations. The settings text box became an unmanageable block of text, mixing code style preferences, project structures, and API usage rules. Because these instructions lived inside local client configurations, sharing them across an engineering team was difficult. Developers had to manually export their settings or copy and paste text blocks into shared documents.

The modern Rules system in Cline version 3.18+ treats instructions as code. Instead of editing a configuration text box, developers write rules in Markdown files. These rules can be scoped globally for personal preferences or locally at the project level. By placing rules directly in the project codebase, teams can version control their prompt engineering guidelines. This version control ensures that every developer and agent on a project works under the same system prompt constraints.

Furthermore, the Cline user interface provides a dedicated Rules panel where users can toggle individual rule files on or off during a chat session. This allows developers to adjust the agent's behavior based on the immediate task. For example, a developer can toggle on a rule for database migrations when writing schema changes, then toggle it off when editing frontend components. This dynamic prompting reduces token usage and prevents the agent from processing irrelevant instructions.

To define project-specific rules, developers create a folder named clinerules in the root of their repository. Within this directory, you can create multiple Markdown files. Cline aggregates these files and appends them to the system prompt. Each Markdown file should focus on a single area of responsibility, such as testing standards, style guidelines, or database conventions.

Below is an example of a production-ready rule file, demonstrating how to define clear constraints:

### TypeScript Coding Standards

#### Role and Context
You are a senior software engineer working on a TypeScript backend application. You write clean, typed code and follow strict safety practices.

#### Coding Constraints
- Always use explicit types. Do not use the 'any' type.
- Prefer interfaces over type aliases for public APIs.
- Use async/await syntax. Do not use raw promises.

#### Verification Workflow
- Read the entire file before editing it.
- After modifying any TypeScript file, run the compiler check.
- Command to run: npm run typecheck

#### Documentation Standards
- Document all public methods with JSDoc comments.
- Explain the rationale for complex algorithms in inline comments.

When structuring rule files, developers should follow a few prompt engineering guidelines:

Define clear roles: Give the agent a specific persona and context. This helps the model select the correct tone and approach for the task.

State constraints explicitly: Use negative constraints to prevent common agent mistakes. For example, instruct the agent not to edit specific configuration files or legacy directories unless explicitly requested.

Specify verification commands: Tell the agent how to verify its changes. If your project has a linter or test suite, define the exact command the agent should run after making edits.

Use structured Markdown: Use headings, lists, and bold text. The structured layout helps the model parse the instructions and follow them in order.

While workspace rules are excellent for team standards, developers also need a way to define personal preferences across all their projects. Cline solves this by supporting both local and global rules.

On macOS and Linux systems, global rules reside in: ~/Documents/Cline/Rules/custom_instructions.md

On Windows, the path is: %USERPROFILE%\Documents\Cline\Rules\custom_instructions.md

You can place your global instructions inside this file. Cline automatically detects this directory and loads the rules for every session. Global rules are ideal for personal configurations, such as your preferred git commit message format, local terminal paths, or editor preferences.

When you start a task, Cline merges the global rules with the workspace rules. If a conflict arises between the two, workspace rules take precedence. This conflict resolution ensures that project-specific standards, such as a team's linting configuration or folder structure, always override a developer's personal global settings. For example, if a developer's global rule file specifies using tabs for indentation, but the project .clinerules file specifies spaces, the agent will use spaces.

This migration to file-based rules also means that legacy configurations are no longer active. In older versions of the extension, developers defined custom instructions using a configuration key in the VS Code settings file. In version 3.18+, this setting is completely unsupported. If you have legacy instructions in your editor settings, you must migrate them to Markdown files in the global rules directory or a local project folder.

To migrate your settings:

1. Open your VS Code settings file and locate the custom instructions key.

2. Copy the text block from the setting.

3. Create the global directory if it does not exist, and save the text as custom_instructions.md.

4. Delete the deprecated setting from your settings file.

Once migrated, these rules appear in the Cline sidebar Rules panel. You can check which rules are active before starting a task. This visual management prevents the agent from running commands or applying styles that conflict with your current workflow.

Manage Cline Custom System Prompt Workspaces

Deploy shared workspaces that auto-index Cline custom system prompt rules and documentation, enabling both developers and AI agents to collaborate with version control, metadata views, and e-signatures. Starts with a 14-day free trial.

Start 14-Day Trial

Prompt engineering for autonomous coding agents requires a different approach than writing prompts for simple chat interfaces. Because agents have tool access, they can modify your filesystem, run terminal commands, and search your codebase. Without clear boundaries, an agent can get stuck in loops, edit the wrong files, or execute destructive commands.

To design rules that prevent these failures, developers can use several system prompt engineering techniques:

Use the read-before-write pattern: Force the agent to read a file completely before proposing any changes. This prevents the model from writing code based on outdated assumptions or incomplete context.

Define explicit test-and-verify loops: Instruct the agent to run your compiler, linter, or test suite immediately after editing a file. If the verification fails, the agent must inspect the error log and fix the code before declaring the task complete.

Constrain file system operations: If the agent only needs to work within a specific folder, define this boundary in your rules. For example, state that the agent should only modify files under /src/components/ and must never touch configuration files in the root directory.

Standardize git commit messages: Instruct the agent to format its commit messages using a specific convention, such as Conventional Commits. This keeps your repository history clean and understandable for human developers.

In addition to coding rules, you can configure prompt engineering rules for documentation and task management. For example, you can require the agent to update a markdown file tracking the project status after every successful code change. This approach creates a live log of the agent's work, which helps human developers review progress and collaborate effectively.

When working in teams, rules must be shared, maintained, and accessed by both human developers and autonomous agents. Choosing where to store and run these shared files and configurations is critical for project consistency.

Developers often start by storing rules files locally on their own machines. While this works for solo projects, local files are isolated. If one team member updates a project standard in their clinerules file, other developers do not receive the update unless it is committed to version control and manually pulled.

Another alternative is using raw cloud storage, such as Amazon S3. Cloud buckets allow centralized storage, but they lack a user interface, require custom API code to read and write, and do not support real-time collaboration. Similarly, platforms like Google Drive or Box provide document sharing, but querying files programmatically requires building custom retrieval-augmented generation pipelines.

Fast.io provides a shared workspace platform designed for agentic teams. By using shared workspaces, teams can store rules files, design documents, and project context in a central location that both humans and agents can access. Fast.io enhances this collaborative environment with several built-in features:

Per-file version history: Every file in a workspace keeps a detailed version history. If an AI agent modifies a rules file or project document incorrectly, developers can view the changes and restore a previous version with a single click.

Append-only audit log: The workspace tracks all file changes, uploads, and views in an append-only audit log. This provides a transparent record of agent activities, helping teams debug incorrect behavior and maintain security compliance.

Intelligence Mode: When you enable Intelligence Mode on a workspace, Fast.io automatically indexes all documents for hybrid search. This system combines full-text and semantic search, allowing agents to query files and rules using natural language and receive direct answers with citations. Agents do not need to read every rule file into their limited token window, instead, they query the workspace to pull only the relevant instructions. You can read more about setting up persistent storage for AI assistants in the storage for agents guide.

Metadata Views: Unlike search or summarization in Intelligence Mode, Metadata Views turn documents into a structured database. Users describe the fields they want, and the system extracts data from files like specifications, contracts, or invoices into a filterable spreadsheet. You can learn more about structured data extraction on the Metadata Views product page.

Collaborative Notes: This feature allows human developers and AI agents to edit rules, notes, and documentation in real-time. An agent can update a shared note with progress, while a developer refines the instructions simultaneously.

When a project is complete, Fast.io allows ownership transfer. An agent can set up a workspace, build the folder structure, configure the project rules, and then hand over the organization to a human client. The human client then takes over the workspace and begins a paid subscription, choosing from the Starter plan at $29/month, the Business plan at $99/month, or the Growth plan at $299/month. To view plan tiers, visit the pricing page. Every new organization starts with a 14-day free trial, which requires a credit card to activate, giving teams time to test their agent workflows before committing.