One repo, five skills directories: how SKILL.md makes agent standards portable

Prathak Malik has published part 2 of a series on keeping AI coding standards in git, with the reference kit pinned at v0.2 ^[1]. Part 1 put the standards in one repo and auto-synced them into Cursor ^[3]; the premise of part 2 is that standards which only work in one tool on one operating system are not team standards at all ^[2].

The mess being cleaned up is config sprawl. Cursor reads skills from `~/.cursor/skills/` and rules as `.mdc` files in `~/.cursor/rules/` ^[4]. Claude Code reads skills from `~/.claude/skills/` and takes standing guidance from `CLAUDE.md` or `AGENTS.md` ^[5]. Copilot in VS Code looks in `.github/skills/` or `~/.copilot/skills/`, with guidance in `.github/copilot-instructions.md` ^[6]. Codex uses `~/.codex/skills/` and `AGENTS.md` ^[7]. That is five candidate skills locations across four tools ^[27], and each one is a place where a standard can be present on your machine and absent on a teammate's.

Two mechanisms hold this together. First, the Agent Skills standard's `SKILL.md` format, which according to the post all four tools understand ^[8]: a skill is a folder containing a `SKILL.md` whose frontmatter carries a `name` and a trigger-rich `description` ^[9], and the sync links that folder into each tool's skills directory ^[10]. The failure mode is quiet. If `name` is not lowercase-hyphen and does not match the folder, tools skip the skill without saying so ^[11], which is why the repo runs a CI check on it ^[12]. That check is the load-bearing piece here, because a silently ignored skill is worse than a missing one: the team believes the guardrail is on.

Second, rules, which the post concedes are less standardized ^[13]. A single portable `AGENTS.md` is the source of truth, consumed three different ways: Claude and Codex read it directly or via a synced `CLAUDE.md` ^[14], Copilot gets a small `.github/copilot-instructions.md` that points at it ^[15], and Cursor keeps its richer `.mdc` rules with `globs` and `alwaysApply` ^[16]. Three consumption paths for one file ^[28] is the honest cost of where these tools currently are, and the kit writes the mapping down in an `adapters/` folder instead of leaving it to memory ^[17].

The operating system layer is where projects like this usually die. v0.2 uses directory junctions via `mklink /J` on Windows, which do not need admin rights the way symlinks do ^[18], and `ln -s` symlinks on macOS and Linux ^[19], so `setup.ps1` and `setup.sh` do the same job on either platform ^[20]. A `.gitattributes` keeps `.sh` files LF-normalized so a Windows clone does not break them ^[21]. The scripts also detect installed tools and only sync into `~/.claude` if it exists ^[22], which avoids the empty-folder litter that gets tooling deleted. After a clone and one setup script ^[23], the author's pitch is that a `git pull` updates every tool on every machine at once ^[24], and tool choice goes back to being personal preference rather than a standards fork ^[25].

Two things to watch. The only automated validation described is the CI check on skill names ^[29], so nothing in v0.2 as written confirms a synced skill actually fires in the tool that now points at it. And symlinks guarantee everyone reads the same file, not that the file is still correct; the author flags exactly that for v0.3 as a nudge to skill to PR loop, plus adapting the kit to other stacks ^[26]. Judge the series on whether that loop produces merged changes, not on the sync.