Rulesync: One Rule Set, Many AI Coding Tools

The multi-tool configuration problem Rulesync targets

Every AI coding tool wants its rules in its own place. Claude Code reads CLAUDE.md, Cursor reads .cursorrules, GitHub Copilot reads .github/copilot-instructions.md, and each one has its own idea of where MCP server settings and ignore patterns belong. A team that uses three assistants ends up maintaining three near-identical documents, and the copies drift the moment someone edits one and forgets the others.

Rulesync's answer is a source-of-truth directory. The README describes it as a Node.js CLI tool that automatically generates configuration files for various AI development tools from unified AI rule files. The audience is a repository with more than one assistant in play: a team standardising rules across members who each prefer a different editor, or a maintainer who wants the same MCP servers available in every tool without retyping JSON.

The scope is wider than rules alone. The supported-tools table in the README lists columns for rules, ignore, mcp, commands, subagents, skills, hooks, permissions and checks, and the coverage is uneven per tool. Codex CLI commands, for example, are documented as global-only. That unevenness matters more than the headline feature list, because it decides which parts of your configuration can actually be generated for the tools you run.

How generation, import and convert differ

There are three distinct flows, and conflating them causes confusion.

Generation runs one way, from .rulesync/**/* outward into each tool's expected paths. The README's quick start calls rulesync generate --targets "*" --features "*", which produces files for every supported target and feature. Selective generation is the point: you can name specific targets rather than star.

Import runs the other way, pulling an existing tool's file into the unified directory. The README gives three examples: rulesync import --targets claudecode reads CLAUDE.md, rulesync import --targets cursor reads .cursorrules, and rulesync import --targets copilot reads .github/copilot-instructions.md. This is the migration path for a repository that already has rules and does not want to rewrite them by hand.

Convert is the odd one out. The README describes it as converting configuration from one AI tool to another directly, without adopting the .rulesync/ source-of-truth workflow, and the example is rulesync convert --from cursor --to copilot,claudecode. No .rulesync/ files are written. That makes convert a one-shot translation, useful when you want to try a second tool without restructuring anything. The trade-off is obvious: after a convert, the two tools have separate files again and nothing keeps them in step. Convert solves a migration, not a maintenance problem.

The repository also carries a .rulesync/ directory and a rulesync.jsonc at its own root, so the project uses its own tool on itself. Whether the generated output is checked in or ignored is not stated in the README.

Installing Rulesync and running a first generate

The README gives three installation routes. The npm global install is the shortest:

npm install -g rulesync

On macOS and Linux there is a Homebrew tap that lives inside the repository itself, which is why the two-argument form is required. The README states plainly that the shorthand brew install dyoshikawa/rulesync/rulesync without tapping first does not work.

brew tap dyoshikawa/rulesync https://github.com/dyoshikawa/rulesync
brew install rulesync

A single-binary installer is also published with each release:

curl -fsSL https://github.com/dyoshikawa/rulesync/releases/latest/download/install.sh | bash

Manual and platform-specific instructions are linked from the installation docs rather than reproduced in the README. After installing, initialise the project. The README says this creates the necessary directories, sample rule files and the configuration file:

rulesync init

If you already have configuration for a tool, import it before generating anything, so the unified directory reflects what you actually use today:

rulesync import --targets claudecode
rulesync import --targets cursor
rulesync import --targets copilot

The README's recommended next step is fetching official skills, then generating everything:

rulesync fetch dyoshikawa/rulesync
rulesync generate --targets "*" --features "*"

What you should see afterwards is a populated .rulesync/ tree plus regenerated files at each target's expected path. The README does not document a dry-run flag for generate, so the first run is the moment to check git status carefully.

Coverage gaps and the cases where Rulesync is the wrong tool

The supported-tools table is the honest part of the documentation, and it should shape adoption. Blank cells are common. JetBrains AI Assistant supports rules, ignore, mcp and skills but not commands or subagents. Meta Muse Code has no commands, subagents, hooks or permissions. GitHub Copilot CLI has no commands. Codex CLI commands are global-only, which means a project-scoped command file will not appear where you expect.

That produces a specific failure mode: you write a command template in .rulesync/, generate, and the file simply does not exist for the tool you care about. Nothing is broken, but the unified directory implies a portability the table does not promise. Read the per-tool mode breakdown in the supported-tools reference before assuming parity.

A second constraint is the direction of truth. Once .rulesync/ exists, edits made directly in CLAUDE.md or .cursorrules are outside the model. The README does not describe a watch mode, a merge strategy or a rollback command, so a generate that overwrites a hand-edited file is recoverable only through version control. Teams that treat generated files as scratch space will fight the tool.

Rulesync is also the wrong choice for a single-tool repository. If everyone uses Claude Code and nothing else, the unified layer adds a directory, a config file and a generation step in exchange for output you could have written once. The same applies to rules that depend on vendor-specific syntax the import step cannot carry across: conversion flattens differences, and flattening is lossy.

Rulesync compared with hand-maintained config and with SuperClaude-style bundles

The realistic alternative is not another synchroniser. It is a shared repository convention: keep CLAUDE.md as the real file, tell Cursor users to read it, and accept that Copilot users maintain a short .github/copilot-instructions.md by hand. That costs nothing to install and nothing to learn. It fails exactly when the number of tools grows past two, or when MCP server definitions need to stay identical across them, because JSON blocks get copied and then diverge silently.

A different alternative is a prebuilt bundle. SuperClaude appears in the related searches and is a distinct kind of project: it ships an opinionated set of commands and personas for one tool, rather than translating one rule set into many tools' formats. If you want someone else's curated workflow, a bundle is the shorter path. If you want your own rules to reach every assistant you run, Rulesync's generate step is the mechanism a bundle does not provide. The two are not substitutes, and the README's rulesync fetch dyoshikawa/rulesync command shows Rulesync can pull official skills in, which is the bundle idea applied to its own ecosystem.

A third option is writing a small script that copies files between paths. That works until a tool changes its expected filename or gains a feature like subagents with its own directory layout. Rulesync's value is that the layout knowledge lives in one maintained place, and the release cadence suggests it is being kept current: the last push to the repository was on 2026-08-25, with v16.17.0 released the same day.

Licence, upgrade cost and what the repository tells you

Rulesync is MIT licensed, both in the repository metadata and in package.json. That permits commercial and private use with the usual requirement to preserve the licence notice; it says nothing about the generated output, which belongs to your project. This is a description of the licence text, not legal advice.

Upgrade pressure comes from the target tools, not from Rulesync's own internals. The version numbers are high and the releases are frequent (v16.15.0, v16.16.0 and v16.17.0 all landed within three days in August 2026), which is consistent with a project tracking other people's file formats. A new assistant or a changed config path means a new release. For a team, that argues for pinning a version in CI and bumping deliberately, rather than installing globally and drifting.

The repository also shows its own maintenance machinery: generated supported-tools tables are checked with scripts/generate-supported-tools-tables.ts, documentation content is checked for drift, and there is a cicheck script that runs formatting, linting, type checking and tests. That is a signal about how the tables you rely on stay accurate, which is more useful to an adopter than any count of stars. What the README does not cover is a migration guide between major versions, so a jump from one v16 release to a much later one is worth testing on a branch first.

Editorial conclusion

Adopt Rulesync if your team runs two or more AI coding tools and wants one reviewed rule set instead of per-tool copies. Skip it if you use one assistant only, or if your rules are tightly bound to a single vendor's syntax that the import step flattens. Before committing, run rulesync import --targets claudecode on a branch and diff .rulesync/ against your existing CLAUDE.md, then run rulesync generate --targets "*" --features "*" and inspect the generated files for the tools you actually use.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes