Team Rules and Skills from a Git repo (context engineering as code)

Ideas Feature Requests
, ,
1

Describe the request

Product: Cursor Teams (Team Rules, Team Skills / plugins, local + Cloud Agents)

Problem

Team context is split across the admin UI, per-project repos, and manual copies. Team Rules are hard to review, diff, or roll back. Many teams keep a separate rules repo and ask every developer to configure Cursor by hand (see forum: API access to set Team Rules). Skills can live in repos or Marketplaces, but there is no org-level git source of truth that Teams treat as authoritative for shared rules and skills together.

We want context engineering like code: branches, PRs, review, CI, tagged releases, and an audit trail when agent behaviour changes.

Proposal

Let a Cursor Team bind to one or more Git repositories (GitHub, GitLab, Azure DevOps, etc.) that define team-wide agent context, for example:

team-context/
.cursor/rules/
.cursor/skills/
AGENTS.md (optional team defaults)

Behaviour we need

  1. Single source of truth — The repo (branch or tag) is what the Team distributes. Dashboard edits either write back to git or teams opt into git-only editing.

  2. Automatic sync — On push/merge (or webhook), Cursor updates what every team member and Cloud Agents load. No clone-an-internal-repo-and-copy-into-~/.cursor.

  3. Same semantics locally and in cloud — Local Agents, CLI, and Cloud Agents read the same team context version (show commit hash or release label in UI).

  4. Governance — Protected branches, required reviews, optional CI (lint rules, validate SKILL.md, block broken paths).

  5. Layering — Documented precedence: Team git context, then project .cursor/, then user settings.

Why this matters

  • Reviewable changes: agent policy changes show up as PRs with diffs.
  • Onboarding: new members get team context when they join the Team.
  • Compliance: prove which instructions applied on a given date (commit SHA).
  • Multi-repo orgs: optional platform context repo plus product repos.
4

Quick clarification — Team Rules vs team marketplace

Team Rules (what we’ve been talking about)

  • Edited in the Cursor Teams dashboard (web UI).
  • Stored on Cursor’s servers, pushed to members automatically.
  • Good for short org-wide text (“always use X”, globs on file types).
  • Not in our git repo — no PR, no diff, no “context engineering like code” for that layer.

Team marketplace (what the docs already offer on Teams/Enterprise)

  • A Git repo (GitHub, Azure DevOps, GitLab, Bitbucket) full of plugins.
  • Each plugin can bundle rules (.mdc), skills (SKILL.md), agents, MCP, etc.
  • Dashboard → Plugins & MCPs → Team Marketplaces → Import from Repo.
  • Admins mark plugins Required / Default on / Default off so everyone gets the same pack.
  • Changes land via git (PRs to that repo); GitHub can Auto Refresh on push.

So today there are two lanes:

Dashboard Team Rules = enforced prose, not git
Team marketplace = git-backed rules + skills, but plugin-shaped and a separate admin flow

What we actually want (default Team UX)

  • Not “learn marketplace vs Team Rules vs project .cursor/.”
  • One obvious team default: org context lives in git (review, CI, rollback), syncs to every member and Cloud Agents — like we already treat AGENTS.md and wiki, not like paste into a dashboard.
  • Team marketplace is close for rules + skills in a repo, but it’s not the main story Cursor tells, and it doesn’t replace Team Rules or feel like first-class “team config as code.”

Bottom line for the forum:

We’re not asking for something impossible — marketplace is a partial answer.
We’re asking for git-native team context to be the normal, documented path for Teams (not a side quest through plugins), with Team Rules either merged into that model or clearly secondary.