One Markdown File to Configure Claude, Codex, Cursor and Copilot

Any team using more than one code assistant knows the problem: each tool has its own instruction format, its own configuration folder, and its own way of interpreting project context. The usual result is a scattered set of files that nobody keeps in sync. A developer named kernalix7 published this week on Hacker News, in the thread Show HN, a repository called ai-project-setup that proposes a straightforward solution: a single Markdown file that serves as the single source of truth for Claude, Codex, Cursor, and GitHub Copilot all at once.

The proposal has the virtue of its simplicity. Instead of maintaining a separate `CLAUDE.md`, `.cursorrules`, `copilot-instructions.md`, and Codex configuration file, the repository proposes a shared structure that each tool can consume, either directly or through a distribution script included in the repo itself.

How the approach works

The heart of the project is a Markdown file with clearly delimited sections: code conventions, project context, constraints, examples of preferred patterns, and architecture notes. The idea is that this file is the only one the team needs to update when project rules change.

The repository also includes a small script that reads that master file and distributes relevant fragments to each destination:

• For Claude Code, it generates or updates the `CLAUDE.md` in the project root, which Anthropic's CLI automatically loads as system context.
• For Cursor, it writes the corresponding `.cursorrules`.
• For GitHub Copilot, it places the content in `.github/copilot-instructions.md`.
• For Codex, it adapts the output to the format its local configuration expects.

There's no special magic: it's a distribution layer over existing formats. What it provides is the discipline of having a single source to edit.

Why it makes sense for mixed teams

In May 2026, it's common for a single development team to have Claude Code users, developers who prefer Cursor, and others working with Copilot directly from VS Code. When each tool has its own instructions, coherence breaks down: assistant A insists on using tabs, B prefers spaces, and code reviews turn into style arbitration.

Kernalix7's proposal tackles that problem without imposing a single tool. Each developer keeps using what they prefer; the master file ensures everyone starts from the same set of instructions.

For teams that already have a well-developed `CLAUDE.md` with architecture context, naming conventions, and dependency constraints, migration is immediate: that file can become the source and the script handles the rest.

Limitations worth keeping in mind

The project currently has a modest starting point: a freshly published repository, no issues, no accumulated stars, and the Hacker News discussion still at zero comments at the time of publication. There's no documented stable version or visible automated tests in the repository.

There's also a conceptual limit: generic instructions work well for style conventions and project context, but each tool has different capabilities. Claude Code, for example, supports skills and subagents that don't have direct equivalents in Cursor or Copilot. A truly unified file tends to settle at the lowest common denominator, which may be enough for many teams but insufficient for those exploiting platform-specific capabilities.

The distribution script isn't bidirectional either: if someone edits the `.cursorrules` directly, that change doesn't propagate back to the master file. The discipline of maintaining one-way flow depends on the team, not the tool.

Who this is useful for right now

The repository has immediate value for individual developers or small teams already jumping between multiple tools and wanting a lightweight way to maintain consistency without additional infrastructure. It's also a good starting point for anyone wanting to build something more robust on top: the core idea is solid even if the current implementation is early stage.

From ClaudeWave, the approach seems sensible as a starting point, though real value will arrive when the community adds support for more tools and, especially, some bidirectional synchronization mechanism that removes the dependency on manual discipline.