Config Guide Cline VS Code

Cline Rules: The Complete .clinerules Guide

Control Cline's AI code generation with organized rule files

Quick Answer

Cline rules are markdown configuration files that control how the Cline AI assistant generates code. Create them in .clinerules/ with numeric prefixes (01-security.md, 02-coding.md) for ordered loading. Cline is free, open-source, and uses a human-in-the-loop approach - perfect for vibe coders who want AI assistance with manual approval gates.

What are Cline rules?

Cline rules are markdown files that tell Cline - the free, open-source VS Code AI assistant - exactly how to write code for your project. They're Cline's equivalent of Cursor rules or Windsurf rules.

What makes Cline unique is its human-in-the-loop philosophy. Unlike other vibe coding tools that execute changes automatically, Cline shows you every file modification and command before running it. Rules help standardize what Cline proposes, while you maintain approval control over what actually gets executed.

Key advantage: Cline is completely free and open source. You only pay for API costs from your chosen model provider (OpenAI, Anthropic, etc.) - no subscription fees or usage limits from the tool itself.

Popular Cline rules resources

Get started faster with community configurations and official documentation:

⭐ 18k+ stars

Cline GitHub Repository Official source code, documentation, and community discussions.

📖 Official Docs

Cline Documentation Official guides for configuration, rules, and best practices.

📖 36k+ stars

awesome-cursorrules Rules templates that work in Cline with minor format changes.

🔗 Cross-tool

CLAUDE.md Guide Claude Code configuration - similar cross-tool config pattern.

How to set up Cline rules

Setting up Cline rules takes less than 5 minutes:

Install Cline extension

Search for "Cline" in VS Code extensions marketplace or run:

VS Code Command Palette

ext install saoudrizwan.claude-dev

Create your rules directory

Terminal

mkdir .clinerules

Create rule files with numeric prefixes

Use numeric prefixes to control loading order. Critical rules (like security) should load first:

Recommended structure

.clinerules/
├── 01-security.md       # Critical - always first
├── 02-architecture.md   # Framework patterns
├── 03-database.md       # Query standards
├── 04-testing.md        # Test requirements
└── 05-style.md          # Coding preferences

Add your security rules

Start with security rules since they're most critical for vibe coding projects:

.clinerules/01-security.md

# Security Standards

## SQL Injection Prevention
- ALWAYS use parameterized queries
- NEVER concatenate user input into SQL strings
- Use Prisma, Drizzle, or native parameterization

## Authentication & Authorization
- Check auth on EVERY server action and API route
- Use middleware for route protection
- Session tokens in HttpOnly cookies only

## Human-in-the-Loop Verification
- Flag any new API endpoints for review before approval
- Highlight all database schema changes
- Mark authentication logic for explicit approval

## Input Validation
- Validate ALL user input with Zod schemas
- Validate in server actions AND API routes
- Sanitize HTML input with DOMPurify

## Secret Management
- Secrets in .env files only, never commit to git
- Use process.env.VARIABLE_NAME server-side only
- Verify .env is in .gitignore

Test your rules

Cline reads rule files automatically when you open a conversation. Test by asking Cline to generate database code and verify it proposes parameterized queries for your approval.

Understanding numeric prefixes

Cline loads rules in alphanumeric order, making numeric prefixes a powerful organization tool. Rules that load first have the strongest influence on AI behavior.

Prefix	Purpose	Example Content
`01-`	Critical security	SQL injection, auth checks, input validation
`02-`	Architecture	Framework patterns, component structure
`03-`	Database	Query patterns, ORM usage, migrations
`04-`	Testing	Test requirements, coverage standards
`05-`	Style	Naming conventions, formatting preferences

Best practice: Keep 01-security.md focused and short (under 500 words). Long security rules get skipped. Be specific and actionable.

The rules bank pattern

The rules bank pattern solves a common vibe coding problem: managing different rule sets for different project types. Instead of deleting and recreating rules, maintain a "bank" of available rules you can swap in and out.

Rules bank structure

project/
├── .clinerules/              # Active rules (loaded by Cline)
│   ├── 01-security.md
│   └── 02-nextjs.md
│
└── .clinerules-bank/         # Available rules (not loaded)
    ├── react-native.md       # Mobile project rules
    ├── python-backend.md     # Backend rules
    └── testing-e2e.md        # E2E testing rules

How to use the rules bank

Switching to mobile development

# Move web rules to bank
mv .clinerules/02-nextjs.md .clinerules-bank/

# Activate mobile rules
mv .clinerules-bank/react-native.md .clinerules/02-react-native.md

Adding E2E testing rules

# Add testing rules to active set
cp .clinerules-bank/testing-e2e.md .clinerules/04-testing-e2e.md

This pattern keeps your rules organized and prevents the "rule overload" problem where too many rules compete for AI attention.

Global rules vs project rules

Cline supports both project-specific and global rules. Understanding when to use each is key to effective vibe coding.

Feature	Project Rules	Global Rules
Location	`.clinerules/` in project root	`~/Documents/Cline/Rules/`
Scope	This workspace only	All workspaces
Version control	Yes - commit with project	No - personal machine only
Best for	Stack-specific patterns, team standards	Personal preferences, company security

Use project rules for

Framework-specific patterns (Next.js, SvelteKit)
Database conventions (Prisma, Drizzle)
Team coding standards
Project architecture decisions

Use global rules for

Personal coding preferences
Company-wide security requirements
Cross-project patterns you always want
API key handling standards

AGENTS.md fallback support

Cline supports AGENTS.md as a fallback when no .clinerules/ folder exists. This provides cross-tool compatibility for teams using multiple AI coding assistants.

Load order: Cline checks for rules in this order:

.clinerules/ folder (preferred)
AGENTS.md in project root
Global rules from ~/Documents/Cline/Rules/

If your team uses Cursor, Claude Code, and Cline across different developers, AGENTS.md provides a single source of truth that all tools respect.

Human-in-the-loop security advantage

Cline's human-in-the-loop approach provides an extra security layer that other vibe coding tools lack. Every file change and terminal command requires your explicit approval before execution.

1 AI Proposes Cline shows code changes in diff view

→

2 You Review Check for security issues, logic errors

→

3 Approve/Reject Accept, modify, or reject changes

Rules that leverage human-in-the-loop

Write rules that flag specific patterns for extra scrutiny:

.clinerules/01-security.md (approval gates)

# Human Review Requirements

## Always flag for review:
- New API endpoints (security surface)
- Database schema changes (data integrity)
- Authentication/authorization logic
- Environment variable usage
- Third-party API integrations
- File system operations

## Explain before proposing:
When suggesting changes to these areas, first explain:
1. What security implications exist
2. Why this approach is safe
3. What alternatives were considered

Security rules for Cline

Security rules are where Cline's manual approval flow shines. AI generates fast, but you verify before it executes. Copy this template to .clinerules/01-security.md:

SQL Injection Prevention

❌ Vulnerable

const user = await db.query(
  `SELECT * FROM users WHERE email = '${email}'`
)

✅ Secure

const user = await db.user.findUnique({
  where: { email: userEmail }
})

Authentication Checks

❌ Missing auth

export async function updateProfile(data) {
  return await db.profile.update({
    where: { id: data.id }, data
  })
}

✅ Auth verified

export async function updateProfile(data) {
  const session = await getSession()
  if (!session) throw new Error('Unauthorized')
  // Verify ownership before update
  return await db.profile.update(...)
}

Input Validation

❌ No validation

export async function createPost(title, content) {
  return await db.post.create({
    data: { title, content }
  })
}

✅ Zod validation

const PostSchema = z.object({
  title: z.string().min(1).max(200),
  content: z.string().max(5000)
})

export async function createPost(input) {
  const data = PostSchema.parse(input)
  return await db.post.create({ data })
}

See our guides on SQL injection, missing authentication, and hardcoded secrets for more patterns.

Cline rules templates by stack

Different tech stacks need different patterns. Here's a copy-paste template for the most popular vibe coding stack:

.clinerules/02-nextjs-supabase.md

# Next.js 14 + Supabase Standards

## Framework Patterns
- Use App Router, not Pages Router
- Server Components by default
- 'use client' only for hooks, event handlers, browser APIs

## Database & Auth
- All queries through Supabase client
- Row Level Security (RLS) policies required on all tables
- Auth checks in middleware: middleware.ts
- Use Supabase Auth, not custom JWT

## API Routes
- Use Server Actions for mutations
- API routes only for webhooks and third-party integrations
- Validate webhook signatures (Stripe, etc.)

## Type Safety
- Strict TypeScript, no 'any' types
- Generate types from Supabase schema
- Zod validation on all external input

For more stack-specific templates, see our Next.js + Supabase security guide.

Cline rules vs other AI coding tools

Each vibe coding tool handles configuration differently. Here's how Cline compares:

Feature	Cline	Cursor	Windsurf
Rules location	`.clinerules/`	`.cursor/rules/`	`.windsurf/rules/`
Format	Markdown files	Markdown + frontmatter	Markdown + frontmatter
Ordering	Numeric prefixes	Activation modes	Activation modes
AGENTS.md support	Yes (fallback)	Yes	No
Execution model	Human-in-the-loop	Auto-execute	Auto-execute
Pricing	Free (pay for API)	$20/month	$15/month

Migration tip: Rules from Cursor or Windsurf work in Cline - just remove the YAML frontmatter and rename files with numeric prefixes.

Best practices

✅ Do

Use numeric prefixes for predictable ordering
Keep security rules short and specific
Show before/after code examples
Use the rules bank pattern for multi-stack work
Review all proposed changes carefully
Version control your .clinerules/ folder

❌ Don't

Write essays - be concise
Mix unrelated topics in one file
Auto-approve without reviewing
Store API keys in rules files
Skip the 01- prefix for security
Overload with too many rules (context pollution)

Optimal rule file length

Keep each rule file focused:

Security rules: 200-500 words (critical, loaded first)
Architecture rules: 300-600 words (framework patterns)
Style rules: 100-300 words (least critical, loaded last)

Frequently asked questions

Does Cline cost money to use?

Cline itself is free and open source. You pay only for the AI model API costs (OpenAI, Anthropic, etc.). This makes it ideal for vibe coders who want full control over their AI spending with no subscription lock-in.

How do numeric prefixes affect rule ordering?

Files are loaded in alphanumeric order. Use 01-, 02-, 03- prefixes to control which rules Cline sees first. Critical rules like security (01-security.md) should load before coding preferences (05-style.md) to ensure they take priority.

What is the rules bank pattern?

The rules bank pattern separates rules into "active" (.clinerules/) and "available" (.clinerules-bank/) folders. Move rules between folders to enable/disable them without deleting. This lets you maintain stack-specific rule sets and swap contexts quickly.

Can Cline use AGENTS.md like other tools?

Yes. Cline supports AGENTS.md as a fallback when no .clinerules/ folder exists. This provides cross-tool compatibility - the same AGENTS.md file works in Cursor, Claude Code, and Cline.

Where should I put global rules that apply to all projects?

Create rules in ~/Documents/Cline/Rules/ (or the equivalent on your OS). These global rules apply to every workspace, making them ideal for personal coding preferences and company-wide security standards.

Why aren't my Cline rules being applied?

Check three things: 1) Folder is named .clinerules/ (not .cline-rules or clinerules), 2) Files use .md extension, 3) Rules are in project root, not a subdirectory. Restart VS Code if rules still do not apply.

Verify Your Rules Are Working

Cline's human-in-the-loop helps catch issues, but some vulnerabilities slip through manual review. VibeShip Scanner automatically detects security issues in your vibe coded projects - a second pair of eyes for your code.

Scan Your Code Free

Official documentation

Cline GitHub Repository - Official source, issues, and discussions
Cline Documentation - Official configuration guides
VS Code Marketplace - Install Cline extension