I second this request!
This is actively breaking my workflow, not just an inconvenience.
What’s going wrong
Cursor ships a set of managed “built-in” skills in ~/.cursor/skills-cursor/ (create-skill, create-rule, create-hook, create-subagent, review, review-bugbot, review-security, autopilot, split-to-prs, canvas, and others). These are treated as first-party product skills. They show up in the agent’s available skill set. They get suggested and followed like any other skill.
I already maintain a deliberate custom skill library for this workspace (~/.cursor/skills/ and mirrored in our agent-skills repo). Those skills encode how we are actually allowed to work here: zero-autonomy conduct, plan shape, Supabase patterns, Docker/Doppler gates, review workflow, and especially git.
The problem is not that Cursor has helpers. The problem is that these managed skills occupy the same job space as my skills, win the agent’s attention, and I have no supported way to turn them off. Deleting or editing files under skills-cursor is temporary. Cursor restores them. The Settings toggle for “Include third-party Plugins, Skills, and other configs” does not cover this folder. So I am stuck with instructions I did not install, cannot remove, and that compete with the rules I do need.
Concrete collisions on my machine
I compared every skill in ~/.cursor/skills-cursor/ against my live custom skills. There is one exact name collision and several harder domain collisions.
1. Git / PR workflow — this is the one hurting production output
My git-workflow skill is strict and non-negotiable for us:
- Feature work goes on branches named
ice-water-{task-description}, never on the base branch itself.
- PRs are opened from that task branch into
ice-water only — not into main/master.
- Every commit and PR must include our Change Request block (MEM-CR-V1) so merge/memory handling works.
- Mutating git operations require explicit per-turn approval. Plan approval is not enough.
- The agent never merges. Never pushes to
ice-water, main, or master. Dirty-tree checks are mandatory before branch/commit/push/PR.
Cursor’s managed skills that sit in the same space:
autopilot — keep a PR merge-ready by triaging comments, resolving conflicts, fixing CI in a loop, pushing fixes, integrating latest remote branch state. That is a different product philosophy: autonomous PR babysitting toward merge-ready. It does not know our branch naming, base branch, Change Request format, or per-turn approval rules.split-to-prs — split work into small PRs, create branches, commit, push, open PRs, often framed around the repo’s default branch. Again: generic Cursor PR conventions, not ours.
When the agent leans on those instead of git-workflow, the outputs look “normal” for Cursor and wrong for us. Branches, PR bases, commit messages, and PR bodies come out without our conventions. I then spend turns arguing the model back onto the skill I actually maintain. That is not a preference conflict. That is forced product guidance colliding with a locked internal workflow.
2. Exact name collision on review
Cursor ships a managed skill named review. So do I.
Cursor’s version is a thin router: ask Bugbot vs Security Review, then run that subagent path.
Mine is a full report-only review workflow: load agent-conduct and plans-define-the-answer, run a required subagent pipeline, optionally dispatch domain reviewers (auth, schema, Supabase, UI, integration contracts, etc.), and produce evidence-backed findings without implementing fixes unless asked separately.
Same skill name. Same “review this” intent. Completely different behavior. Cursor’s managed review-bugbot and review-security amplify that by owning the “review” space with generic Cursor review products instead of our review skill and our execution-breakdown-review skill.
3. Authoring / control-plane skills fighting our locked system
We already have a locked way to create and maintain skills, rules, hooks, and subagents in this ecosystem. Cursor still injects:
create-skill — teaches generic Cursor SKILL.md authoring into ~/.cursor/skills / .cursor/skills, without our conduct, plan, memory, or Change Request conventions.create-rule — teaches generic .cursor/rules / AGENTS.md patterns that compete with our agent-conduct and workspace rules.create-hook — will happily invent generic hooks.json scripts over our real hook stack (approval gates, contract gates, memory recall, etc.).create-subagent — points at generic .cursor/agents/ setups instead of our existing Task/subagent map.migrate-to-skills — will convert rules/commands into skills without respecting how our skill system is structured.
Those are not “extra tools sitting quietly.” They are alternate instruction manuals for the same jobs. When the agent follows them, it drifts away from the system we already built and maintain.
4. Softer collisions that still steal attention
canvas pushes visual canvas artifacts for analytical / tabular / MCP-heavy output even when we want plain chat and plan documents.automate owns “automation” language around Cursor Automations, which can collide with our n8n / automation skill surface.- Cloud env skills (
env-setup, migrate-to-builds, onboard) sit next to our Doppler/Docker verification rules and can pull setup advice into the wrong environment model.
Less urgent than git/review, but same root issue: unmanaged skills I cannot disable keep entering the decision space.
What I tried / current state
- Custom skills are present and intentional under
~/.cursor/skills/.
- Managed skills remain under
~/.cursor/skills-cursor/ and are synced/restored by Cursor (there is a sync manifest; edits do not stick).
- The third-party import toggle does not solve this, because these are not third-party roots like
.claude / .codex. They are Cursor-managed first-party skills living in my home directory as if they were mine.
- There is no settings control to disable
skills-cursor globally or per skill.
- Filesystem workarounds (delete, move, chmod/immutable, bind-mount hide) are fragile and get undone on update/sync. That is not a product solution.
Why this matters
I am not asking Cursor to stop shipping built-ins for people who want them. I am saying: if I maintain a stricter, domain-specific skill system, Cursor’s non-optional managed skills should not silently compete with it.
Right now they do. The highest-cost failure mode for me is git: PRs and commits that do not match our required convention, because Cursor’s PR skills are still in the room and the model treats them as legitimate guidance. That creates cleanup work, wrong artifacts, and constant correction loops. The second failure mode is review and authoring drift: same names / same jobs, wrong playbook.
What I need
A first-class way to disable Cursor’s managed skills under ~/.cursor/skills-cursor/, ideally:
- A global toggle: enable/disable built-in Cursor skills.
- Per-skill enable/disable in Settings → Rules, Skills, Subagents.
- The same control for IDE and
cursor-agent CLI.
Until that exists, users with serious custom skill systems cannot make their own skills authoritative. Cursor’s defaults stay injected, unremovable, and actively harmful when they conflict.
Please treat this as a real opt-out gap, not just a storage complaint. The restore behavior is part of the problem, but the deeper problem is forced competition with user-owned skills that already define the correct workflow.