DEV Community: Prathak Malik

One set of AI standards, every tool: Cursor, Claude Code, and Copilot

Prathak Malik — Fri, 14 Aug 2026 07:55:32 +0000

Part 2 of the agent-standards-as-code series. Part 1 made the case for versioning your AI standards as code. This post makes them work across tools and operating systems. Code pinned at v0.2.

In part 1 we put our AI coding standards in one git repo and auto-synced them into Cursor. Great — until a teammate says "I use Claude Code," another says "we're on Copilot in VS Code," and half the team is on macOS while you're on Windows.

If your standards only work in one tool on one OS, they're not really team standards. Here's how v0.2 fixes that.

The portability problem

Each tool reads its config from a different place, in a slightly different format:

Cursor: skills in ~/.cursor/skills/, rules as .mdc in ~/.cursor/rules/.
Claude Code: skills in ~/.claude/skills/, guidance in CLAUDE.md / AGENTS.md.
Copilot (VS Code): skills in .github/skills/ or ~/.copilot/skills/, guidance in .github/copilot-instructions.md.
Codex: skills in ~/.codex/skills/, guidance in AGENTS.md.

Two things save us from writing four different content sets.

1. Skills are already portable

The Agent Skills standard defines a SKILL.md format that Cursor, Claude Code, Copilot, and Codex all understand. A skill is a folder with a SKILL.md whose frontmatter has a name and a trigger-rich description. Write it once, it runs everywhere. The sync just links that folder into each tool's skills directory.

(One sharp edge: the name must be lowercase-hyphen and match the folder, or tools silently skip it. The repo's CI enforces this so you can't ship a broken skill.)

2. `AGENTS.md` is the portable base for rules

Rules are less standardized. So we keep a single portable AGENTS.md — the tool-agnostic standing guidance — and let each tool consume it:

Claude/Codex read AGENTS.md (or a synced CLAUDE.md) directly.
Copilot gets a tiny .github/copilot-instructions.md that points at AGENTS.md.
Cursor keeps its richer .mdc rules (which support globs and alwaysApply).

The adapters/ folder documents exactly where each tool expects things, so there's no guessing.

Git repo: skills/ + rules/ + AGENTS.md
        │  setup.(ps1|sh) + git hooks
        ╚
  ├───────────↴────────────↴───────────↴──────────└
Cursor     Claude Code   Copilot     Codex
(junction) (symlink)     (.github)   (symlink)

Cross-platform: junctions vs symlinks

The sync uses the right primitive per OS automatically:

Windows: directory junctions (mklink /J) — no admin required (unlike symlinks).
macOS/Linux: symlinks (ln -s).

So setup.ps1 and setup.sh do the same job on either platform. A .gitattributes keeps .sh files LF-normalized so they don't break when cloned on Windows.

The scripts also detect installed tools — they only sync into ~/.claude if it exists, so nobody ends up with empty folders for tools they don't use.

Try it

git clone https://github.com/prathakmalik/agent-standards-kit.git
cd agent-standards-kit
# Windows:      ./scripts/setup.ps1
# macOS/Linux:  ./scripts/setup.sh

Whatever tools you have installed now share the same skills and rules. Change the repo, git pull, and every tool on every machine updates together.

Why this matters

Tool choice becomes a personal preference again, not a standards fork. A new hire on Claude Code gets the exact same guardrails as a veteran on Cursor — from the same reviewed source of truth.

Coming up next (v0.3): a source of truth is only useful if it stays true. Next post: the nudge -> skill -> PR loop that keeps your standards from rotting, plus how to adapt the kit to any tech stack.

⭐ the repo if this is useful — it genuinely helps.

Your CLAUDE.md doesn't scale. Version your AI standards as code.

Prathak Malik — Sat, 25 Jul 2026 13:07:57 +0000

Every team using AI coding agents starts the same way: someone drops a CLAUDE.md (or .cursorrules, or a copilot-instructions.md) into a repo. It works. So the next repo gets one too. And the next.

Then you look up and you have 20 repos, 6 teammates, and 3 different AI tools — and no two of those config files are the same. Which one is right? Nobody knows.

I hit this wall running an integration platform with dozens of small repos. This post is the pattern I landed on, and a small open template you can clone to do the same.

Why a single instructions file breaks

A single file is perfect for one repo and one person. At team scale it fails in five predictable ways:

It doesn't scale. Every repo gets a slightly different copy. There's no "the standard" — there are 20 forks of it.
It drifts. Someone improves the file in one repo. That improvement never reaches the other 19.
It's unversioned. No history, no ownership, no review. Your "AI brain" is the one artifact in your stack nobody code-reviews.
It's tool-locked. Cursor's format isn't Claude's isn't Copilot's. Switch tools and you start over.
It rots. The code changes; the instructions don't. Six months later the agent is confidently working from a map of a city that's been rebuilt.

None of these are exotic. They're just what happens when a copy-pasted file meets a growing team.

What already exists (and what it doesn't fix)

Curated rule lists (e.g. awesome-cursorrules) are great for inspiration, but they're copy-paste, single-tool, and have no sync or freshness.
Skill/agent sync tools distribute tools across agents. Useful — but they solve distribution, not your team's standards, versioning-as-review, or the rot problem.
The Agent Skills standard + AGENTS.md are the right substrate to build on, not competitors.

The gap: nobody treats the standards themselves as code — owned, versioned, reviewed, and automatically distributed.

The pattern: standards-as-code

Three moves:

Put your standards in one git repo. Two kinds of artifact:
- Rules — standing behavior ("always validate input", "never log PII").
- Skills — task workflows ("here's how to cut a release"), in the portable SKILL.md format.
Auto-sync them into your editor. A setup script links skills/ and rules/ into your tool's config directory. Git hooks re-run the sync on every pull / checkout / rebase.
Change them through pull requests. Improving a standard is now a reviewed diff, not a silent edit in one repo.

Git repo (source of truth)          ~/.cursor/
  skills/  ──────────────└            skills/   (junction/symlink)
  rules/   ──────────────┤  setup +   rules/    (synced .mdc)
                         └── git hooks ─────────→ every workspace, every teammate

Because rules sync to the user level, they apply in every workspace automatically. Update the repo, everyone git pulls, and the whole team's standards move together — no per-repo copies.

Why this beats a bare `CLAUDE.md`

	standards-as-code	bare `CLAUDE.md`
Scales across repos	Yes (one source)	No (N copies)
Versioned + PR-reviewed	Yes	No
Auto-distributed	Yes (sync + hooks)	Manual
Freshness mechanism	Yes (later in the series)	No

It's the difference between a shared library and a code snippet everyone pastes.

Try it (v0.1)

I packaged the mechanism as an open template: agent-standards-kit (this post pins v0.1).

git clone https://github.com/prathakmalik/agent-standards-kit.git
cd agent-standards-kit
./scripts/setup.ps1     # Windows/Cursor; no admin needed

Restart Cursor and your sample skills + rules are live. Swap in your own — the repo ships templates and a de-identified worked example.

My honest take

This is not another skills manager — that niche is crowded. It's a methodology plus a starter template, proven on a real multi-repo platform. Its value is the boring, durable stuff: team+repo scoping via plain git, review of changes, and (coming in this series) a loop that keeps the standards from rotting. If you're one dev on one repo, a single file is genuinely fine. The moment there's a team, treat your AI standards like code.

Coming up next (v0.2): One source of truth is great — but your team doesn't all use the same AI tool. Next post: making the same skills and rules work across Cursor, Claude Code, and GitHub Copilot, with cross-platform setup (bash and PowerShell). Star the repo to follow along.

If you found this useful, a ⭐ on the repo helps more than you'd think.