Cline is an installer target
Cline reads .cline/skills/ in a project and ~/.cline/skills/ under your home
directory. That is a folder of its own, so the installer writes it at both scopes, and
the AGENTS.md block covers the pointer, because Cline reads AGENTS.md as a
cross-tool rule source.
One field makes it unlike the rest of the table. Cline also loads .claude/skills/
beside its own folder, so a project installed for Claude Code and Cline holds the same
skill names twice, in two folders Cline reads. It takes readsAlso for that, and the
duplicate warning fires, the same collision OpenCode already had.
There is a second behaviour that belongs to Cline alone, and it is now written down in
the README and the guide instead of being left in the documentation: when a global
skill and a project skill share a name, the global one wins. Every other agent here
resolves it the other way round. So a stale global install silently outranks a fresh
project one, with no error to tell you.
The Cline plugin door
cline plugin install https://github.com/miqdadbadjuber/anti-slop.git
This door is shaped differently from the Kimi Code and Cursor ones. Cline reads its
manifest out of the repository's root package.json, under a cline field, which
makes this the first door that needed a root manifest and the first that changed the
repository's own shape to open. The entry it points at, .cline-plugin/plugin.js,
registers no tools and no hooks: the payload is the skills/ folder the plugin
bundles, which Cline discovers on install.
Updating carries --force, because Cline otherwise keeps what is already installed and
tells you so:
cline plugin install https://github.com/miqdadbadjuber/anti-slop.git --force
The root package.json joins the version check, so a version bump has to reach it too.
Read this before you pick the plugin over the installer
Cline's own documentation limits plugins to the SDK, the CLI, and Kanban, and states
that the feature does not apply to the VS Code and JetBrains extensions. So this door
covers a Cline CLI install and not an editor install. If you run Cline inside an
editor, use the installer: it writes the same skills into .cline/skills/, which both
the CLI and the extensions read.
The premise this slot was written on did not survive
The roadmap row for this release promised "one .agents/skills reader, confirmed on
its own rather than assumed from the shared folder". Reading the vendor's own
documentation is what broke it. Cline's docs never mention .agents/skills anywhere,
and they list .cline/skills/, .clinerules/skills/, and .claude/skills/ at project
scope and ~/.cline/skills/ at global. So this was never a shared-folder door at all,
and the row was rewritten before any code was written.