Overview

Understand how Rules, Workflows, Skills, and Hooks work together to customize Cline.

Out of the box, Cline is a general-purpose AI assistant. Customizations transform it into an expert on your codebase, your team’s conventions, and your workflows. Instead of repeating the same instructions every task, you define them once and Cline follows them automatically.

Cline offers four systems for this: Rules, Workflows, Skills, and Hooks. Each serves a different purpose and activates at different times.

Quick Comparison

Feature	Purpose	When Active	Best For
Rules	Define how Cline behaves	Always (or contextually)	Coding standards, project constraints, team conventions
Workflows	Step-by-step task automation	Invoked with /workflow.md	Repetitive processes, release procedures, setup scripts
Skills	Domain expertise loaded on-demand	Triggered by matching requests	Specialized knowledge, complex procedures, institutional expertise
Hooks	Inject custom logic at key moments	Automatically on specific events	Validation, enforcement, monitoring, automation triggers

Understanding Each Tool

Rules are always-on guidance. Use them when you want Cline to consistently follow certain patterns: coding standards, naming conventions, architectural constraints, or project-specific context. Rules shape how Cline works across all tasks. For example, a rule might say “always use TypeScript” or “follow the repository pattern for data access.”

Workflows are explicit task scripts you invoke on demand. Use them when you have a repeatable multi-step process that should run the same way every time. Type /release.md and Cline executes your release sequence: bump version, run tests, update changelog, commit, tag, push. Workflows define what to do, step by step.

Skills are domain expertise that loads only when relevant. Use them when you have extensive knowledge that would waste context if always active. Cline sees skill descriptions at startup and activates the full instructions only when your request matches. A data analysis skill might include pandas patterns, visualization preferences, and output formats that Cline only loads when you’re working with data files.

Hooks are programmatic guardrails that run automatically at key moments. Use them when you need to validate, enforce, or extend Cline’s behavior with custom code. A hook might block .js file creation in a TypeScript project, run linters before saves, or notify external services after deployments.

Example: A Release Process

Consider how all four work together for releasing a new version:

1. Rules ensure Cline follows your team’s commit message format and versioning policy
2. Workflows provide the explicit /release.md sequence: bump version, update changelog, tag, push
3. Skills offer deep knowledge about your CI/CD system that Cline loads when deployment questions arise
4. Hooks validate that tests pass before allowing any commit or that the changelog was actually updated

Storage Locations

All four systems support both global and project-specific configurations:

System	Global Location	Project Location
Rules	~/Documents/Cline/Rules/	.clinerules/
Workflows	~/Documents/Cline/Workflows/	.clinerules/workflows/
Skills	~/.cline/skills/	.cline/skills/
Hooks	~/Documents/Cline/Hooks/	.clinerules/hooks/

When to Use Each

Start with project storage. Most customizations belong in your project’s directory because they’re tied to that specific codebase. Team coding standards, deployment workflows, and architectural constraints all live with the code they describe. This also means your customizations travel with the repository, so collaborators get them automatically and changes can be reviewed in pull requests.

Use global storage for personal preferences. If you find yourself adding the same customization to every project, move it to global storage. Your preferred communication style, personal productivity workflows, and tools you use everywhere belong here. Global customizations apply to all projects but stay out of version control, so they won’t affect your teammates.

When names conflict, project-specific configurations take precedence (except for Skills, where global takes precedence). This lets you override global defaults for specific projects when needed.

Security Considerations

Always review customizations before adding them to your projects. Only use customizations from sources you trust.

Customizations are powerful. They shape how Cline writes code, execute commands automatically, and influence every interaction. Treat customization files with the same scrutiny you’d give any code running in your environment.

Best Practices

Review any customization file before adding it to your project or global configuration. Understand what it does and why.

When downloading customizations from GitHub repositories, community shares, or other external sources, verify the source:

• Is the author reputable?
• Has the community reviewed it?
• Does the code do what it claims?

Look for dangerous commands:

• Shell commands that delete files (rm, del)
• Commands that transmit data (curl, wget with POST)
• File operations outside your project directory
• Commands that modify system configuration

Keep your customizations in version control so you can track changes, review diffs, and roll back if something goes wrong. When creating hooks, use the most restrictive event triggers necessary. Don’t run hooks on every file save if you only need them before commits.