Cline (cline)

• Rules: one file each under .clinerules/.
  • When Codex or another tool that copies rules into AGENTS.md writes that file, its ## Rules block holds every rule without a scope. Cline loads that file by default, so an always-on rule gets no .clinerules/ file and loads once.
  • Rules with paths keep their file. So does a rule whose text differs for Cline (a ::target cline fence or a path variable).
  • Keep AGENTS.md on in Cline's Rules panel. Otherwise Cline misses the rules that have no file of their own.
  • Listing AGENTS.md under sync.unmanaged makes every rule keep its file. Check the effect on other targets sharing that file.
• Rules layouts: Cline searches both .clinerules/ and .cline/rules/ in VS Code, Desktop, and the CLI, and deprecates neither. .clinerules/ is the default because the VS Code Rules panel creates rules there (outputs.cline.rules-dir: .cline/rules picks the other). Sync writes one and removes the files it wrote earlier in the other, so rules never load twice.
• Rule activation: a scoped rule gets paths limited to its folder, even with alwaysApply: true. A rule without a scope gets native paths from its file selector with alwaysApply: false, or with globs other than a catch-all such as **/* and no alwaysApply. With no usable selector, sync reports it. See Cline conditions and file-pattern limits for directory rules.
• Agents: always at .cline/agents/, whatever the rules folder is set to. All three Cline readers use <workspace>/.cline/agents.
  • <name>.yml has frontmatter (between --- lines) with the required name and description. The spec body follows as the system prompt, with no added heading.
  • Cline loads only .yml and .yaml files that open with ---, and rejects an empty name or description. A missing description falls back to the name.
  • The generated-file comment sits inside the prompt. Above the --- line, the file would not load.
  • Set tools, skills, providerId, modelId, and maxIterations under x-cline.
• Skills: .cline/skills/<name>/SKILL.md, as Cline's skills docs recommend. A flat file in the rules folder never loads as a skill. Frontmatter has name and description. Files next to the skill are copied unchanged.
  • Cline documents no field that keeps a skill user-only: any enabled skill runs from the chat input as /<name>, and the model can also pick it (Cline skills). Its disabled field hides the skill from the person too. So disable-model-invocation is dropped with a note, and commands are skipped.

Hooks

Cline finds a hook script by file name only, and it has two hook runtimes.

• The VS Code extension runs an executable named after the event with no extension, such as .clinerules/hooks/PreToolUse (source). It turns the SDK runtime off, so nothing runs twice (source).
• The SDK runtime, which the Cline CLI runs, lists ten names (TaskStart, TaskResume, TaskCancel, TaskComplete, TaskError, PreToolUse, PostToolUse, UserPromptSubmit, PreCompact, SessionShutdown). It scans <workspace>/.clinerules/hooks and <workspace>/.cline/hooks and runs every file with that name and an allowed extension (no extension counts).

So sync writes one file per event to .clinerules/hooks/<Event>, the only layout both run, once each. The next sync removes an older .cline/hooks/<Event>.sh that sync wrote. Sync overwrites a hand-written .clinerules/hooks/<Event> for an event a spec uses. List it under sync.unmanaged to keep your own. A single-file .clinerules blocks .clinerules/hooks/. Sync replaces it only when a rule spec holds its content. So run agnostic-ai import cline first, or set outputs.cline.hooks-dir: .cline/hooks, which only the Cline CLI reads.

Cline's docs barely cover this. The hooks page is a stub that points to SDK Plugins (a TypeScript API). Only the config reference lists hooks, under .cline/hooks/ and in the older .clinerules/hooks/ folder.

• Each script starts with #!/usr/bin/env bash, and the generated-file comment follows it. The extension runs the file through its shebang, and the SDK reads the shebang to pick bash.
• matcher and timeout do nothing, and sync says so. A hook runs on every occurrence of its event and must filter itself. Cline uses its own timeout. A portable match kind is the exception: the script runs the command only when the event data names one of the kind's tools, such as run_commands (Cline CLI) or execute_command (VS Code extension) for shell. Tool names in target overrides are matched as literal JSON values, including quotes, backslashes, and newlines. They cannot add shell commands.
• Two specs on one event share one script, in spec order, and share stdout. Each spec's command runs in its own subshell under set -e. So a cd, variable, or exit 0 in one spec does not affect the next, and a failure other than exit 2 stops the script with its code. Cline reads stdout as control JSON (the last HOOK_CONTROL<TAB><json> line wins), so send anything else to stderr.
• Exit 2 blocks. Cline ignores the exit code: only stdout {"cancel": true} blocks (source). The current VS Code extension honors valid reply JSON even after a nonzero exit. So the script turns a command's exit 2, as on Claude Code, into a last HOOK_CONTROL<TAB>{"cancel": true, "errorMessage": ...} line with the command's stderr, and exits 0. Any exit 2 counts, including a tool error such as grep on a missing file. A cancel stops the whole Cline run, not only that tool call.
• On Windows the VS Code extension runs only <Event>.ps1 (source). For a TaskStart hook with x-cline.runtime: vscode and commandWindows, a Windows sync also writes its native .ps1 companion. Unix sync omits it so the SDK does not run a second PowerShell hook. Normal ledger cleanup removes a previously owned companion when syncing on Unix.
• agnostic-ai hook run runs a hook's script with bash, Cline's event data, and its 120 second timeout, before a session does.
• PreCompact has no runtime event yet. Its script is written and reported but never runs.
• Any other event gets a sync note instead of a file.

Workflows

With outputs.cline.workflows-dir set to .clinerules/workflows, each agent is also written as <dir>/<name>.md, which you run from chat as /<name>.md. An italic description, if any, comes before the body. The key is opt-in because a workflow repeats the agent in .cline/agents/<name>.yml.

Cline's workflows doc page now redirects to the rules page. The config reference lists .cline/workflows/ and the older .clinerules/workflows/, and Cline's resolver searches both. The VS Code extension reads only .clinerules/workflows and keeps it out of the rules scan, so a workflow never doubles as a rule. With .cline/workflows, only the CLI and SDK see them, and sync says so.

Cline still reads a single-file .clinerules. It imports as one rule, clinerules.md, with its paths kept, and the .clinerules/skills/ lookup is skipped. Sync and doctor --fix then replace the file with a .clinerules/ folder, as Cline does, but only when its content matches a rule spec. Otherwise sync, --check, --dry-run, and doctor --fix fail and leave it alone. Run agnostic-ai import cline first.