Cline Rules: How to Configure Cline for Your Project

What is Cline?

Cline is an open-source AI coding agent that runs inside VS Code. Unlike copilot-style completions, Cline acts autonomously: it reads files, runs terminal commands, edits code, and completes multi-step tasks without you manually directing each action. It supports every major AI provider (Anthropic, OpenAI, Google Gemini, AWS Bedrock, and more), so you can plug in whatever model your team prefers.

What sets Cline apart is its transparency. Every file read, command run, and edit made is shown in a step-by-step log you can inspect and approve. Pair that with persistent project context through Cline rules, and you have an agent that genuinely understands your codebase.

How .clinerules works

Cline's configuration system is straightforward. You create a .clinerules file in your project root (or a .clinerules/ folder for more complex setups), and Cline reads it automatically at the start of every task.

The rules file is plain Markdown. No special syntax, no proprietary format, just instructions written for the AI to follow.

# Project rules

## Tech stack
- Next.js 15 with App Router
- TypeScript (strict mode enabled)
- Tailwind CSS for styling
- Drizzle ORM with PostgreSQL

## Coding style
- Named exports for all components
- Async/await, not .then() chains
- Descriptive variable names — avoid single-letter vars outside loops

Cline treats this as a persistent system prompt. Every task starts with this context loaded, so you never have to repeat yourself.

.clinerules file vs .clinerules/ folder

For larger projects, you can split rules into a folder:

The folder approach lets you organize rules by domain: one file for API patterns, another for testing conventions, another for component structure. Cline merges them all at runtime.

Writing effective Cline rules

The quality of your AI output depends almost entirely on rule quality. Vague rules produce vague code. Specific rules with examples produce code that matches exactly what your team expects.

1. Describe your stack explicitly

Don't assume Cline knows which libraries you're using or which patterns you prefer. Be explicit:

## Stack and tooling

- **Runtime**: Node.js 22, no Bun or Deno
- **Framework**: Express 5 with TypeScript
- **Database**: PostgreSQL via Drizzle ORM — never raw SQL strings
- **Validation**: Zod for all request/response schemas
- **Testing**: Vitest, not Jest
- **Auth**: JWT tokens, never sessions

This 10-line block prevents Cline from reaching for the wrong library on every task.

2. Show the pattern you want with examples

Cline learns from examples much better than abstract instructions. Instead of "write clean API routes," show what clean looks like:

## API route pattern

All routes follow this structure:

\`\`\`typescript
export async function POST(req: Request, res: Response) {
  const body = RequestSchema.parse(req.body);

  const result = await db
    .insert(users)
    .values(body)
    .returning();

  res.json({ data: result[0] });
}
\`\`\`

- Always validate with Zod before touching the database
- Use .returning() to avoid a second query
- Never return the full row — pick only needed fields

3. Define hard boundaries with "do not" rules

Cline is helpful by default, which means it will add things you didn't ask for if you don't set limits:

## Do NOT

- Do not add console.log statements — use the logger utility
- Do not create new npm scripts without asking first
- Do not install dependencies automatically — list what you need and ask
- Do not modify \`package.json\` without explicit instruction
- Do not use \`any\` in TypeScript — use \`unknown\` and narrow types

These boundaries prevent the most common AI frustrations: unnecessary changes, unwanted dependencies, and type shortcuts.

4. Describe your file structure

Cline works better when it knows where things belong:

## File structure

src/
  api/          # Express route handlers
  services/     # Business logic — imported by routes
  db/
    schema.ts   # Drizzle table definitions
    queries/    # Reusable query functions
  lib/          # Shared utilities (logger, errors, config)
  types/        # Shared TypeScript types

tests/
  unit/         # Unit tests matching src/ structure
  integration/  # End-to-end API tests

When Cline knows where services/ lives and why, it puts new business logic there instead of inlining it in route handlers.

Organizing rules for large projects

For projects with multiple teams or complex conventions, the .clinerules/ folder structure scales well:

.clinerules/
  00-overview.md        # Project summary, goals, non-negotiables
  01-stack.md           # Tech stack and library choices
  02-api-patterns.md    # Route structure, validation, error handling
  03-database.md        # Schema conventions, query patterns, migrations
  04-frontend.md        # Component structure, state management
  05-testing.md         # Test structure, mocking, coverage expectations
  06-security.md        # Auth rules, input validation, secrets handling

The numbered prefix sorts files consistently. The 00-overview.md file sets the most important context first: project mission, critical constraints, things that should never be violated.

What to put in overview

# Project overview

This is a B2B SaaS platform for enterprise customers. Security and data
isolation are non-negotiable — never mix tenant data.

## Non-negotiable rules
1. Every database query MUST include a tenantId filter
2. All user inputs MUST be validated before processing
3. Secrets NEVER appear in logs or error messages
4. Every PR requires passing tests — never skip the test suite

## Current priorities
- We are in active migration from Express to Fastify
- New routes should use Fastify, existing routes can stay on Express for now

Putting critical constraints in the overview means they're always in context, regardless of which other rule files Cline loads.

Cline rules vs other AI coding tools

Cline, Cursor, Claude Code, and Windsurf all use different rules formats but solve the same problem: giving your AI persistent project context.

The concepts transfer directly across tools. What makes a good Cline rule also makes a good Cursor rule. The main differences are file location and rule syntax. Both Cursor and Cline support glob-based conditional rules via frontmatter, while Claude Code uses a paths field in its rules files.

If your team uses multiple tools, you'll find yourself writing the same conventions multiple times in different formats. That's the core problem that localskills.sh solves: write once, install anywhere.

Read more in AI coding rules across tools for a full breakdown of format differences.

Common mistakes when writing Cline rules

Too vague

# Bad
Write clean, readable code with good patterns.

# Good
Functions should have a single responsibility. If a function exceeds 40 lines,
consider splitting it. Name functions as verbs (getUserById, validateEmail).

Contradictory rules

When rules conflict, Cline will pick one interpretation. Audit your rules for contradictions, especially if multiple people contributed them.

# Conflicting (bad)
Always add JSDoc comments to functions.
Keep code minimal — avoid unnecessary comments.

# Clear (good)
Add JSDoc comments to public API functions only.
Internal utility functions don't need JSDoc unless the logic is non-obvious.

Missing error handling conventions

Error handling is one of the most inconsistent areas in any codebase. Define it explicitly:

## Error handling

- Throw typed errors from the \`AppError\` class, not plain \`new Error()\`
- API routes should catch errors and return structured JSON, never expose stack traces
- Log errors with the logger utility at the point they're caught, not where they're thrown

\`\`\`typescript
// Correct
try {
  const user = await getUser(id);
} catch (err) {
  logger.error('Failed to get user', { id, err });
  throw new AppError('USER_NOT_FOUND', 404);
}
\`\`\`

Sharing Cline rules across your team

The hard part isn't writing rules. It's keeping them consistent across repos and team members.

You could commit .clinerules to every repository, but then updates require PRs in each repo. You could put rules in a shared doc, but then developers manually copy them. Neither scales.

localskills.sh gives you a rules registry. Publish your Cline rules once:

# Install the CLI
npm install -g @localskills/cli

# Log in and publish your rules
localskills login
localskills publish

Then any developer installs them in seconds:

# Install into Cline (writes to .clinerules/)
localskills install your-team/project-rules --target cline

Rules are versioned, so you control when to adopt updates, or you can pin to a version. The CLI handles format differences between tools automatically.

The same skill can target multiple tools at once:

# Install across Cline, Cursor, and Claude Code simultaneously
localskills install your-team/project-rules --target cline cursor claude

This is particularly valuable for teams that mix tools. Your frontend developers might use Cursor, your backend team might use Cline, and some engineers use Claude Code. With localskills.sh, everyone gets the same conventions in the format their tool expects.

Read more about publishing your first skill for a step-by-step walkthrough, or check the guide on best practices for AI coding rules to level up your rule quality.

Keeping rules up to date

Rules aren't set-and-forget. As your codebase evolves (new libraries, architectural changes, lessons learned), your rules should evolve too.

A few practices that help:

Treat rule updates like documentation PRs. When you make a significant architectural decision, add it to .clinerules in the same PR. Future AI sessions will benefit immediately.

Review rules in onboarding. When a new developer joins, have them read the rules as part of their onboarding. Fresh eyes catch outdated or confusing instructions.

Add rules when you catch mistakes. If Cline does something wrong twice, write a rule to prevent it. Every recurring mistake is a missing rule.

If your team uses localskills.sh, rule updates are versioned and distributed automatically. Update the published skill, bump the version, and developers pull updates on their next localskills pull.

Comparing Cline to Claude Code

If you're choosing between Cline and Claude Code, the rules system is one of the differentiators. For a detailed comparison, see Cursor vs Claude Code vs Windsurf (the same tradeoffs apply to Cline).

The short version: Cline runs inside VS Code, supports every AI provider, and gives fine-grained control over what actions it takes. Claude Code runs in the terminal, is tightly integrated with Anthropic's models, and is preferred by developers who live in the command line. Both benefit enormously from well-written rules.

---

Ready to share your Cline rules across your team and every AI tool you use? Sign up for localskills.sh and publish your first skill today.

npm install -g @localskills/cli
localskills login
localskills publish