I had four AI coding assistants and the same config in five places. Here's what I built.

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3203307) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Serhii Zhabskyi Posted on Apr 28 I had four AI coding assistants and the same config in five places. Here's what I built. #ai #tooling #typescript #productivity A while back my repo looked like this: CLAUDE.md # rules for Claude Code .claude/agents/code-reviewer.md # agent definitions .claude/skills/refactor/SKILL.md # skill packs .claude/commands/deploy.md # slash commands .claude.json # MCP servers .cursor/rules/typescript.mdc # rules for Cursor .cursor/mcp.json # MCP servers (different schema) .github/copilot-instructions.md # rules for Copilot .github/agents/code-reviewer.md # agents (different format) .continue/rules/typescript.md # rules for Continue .continue/mcpServers/ # MCP servers (yet another schema) Enter fullscreen mode Exit fullscreen mode Same rule - "no any, prefer unknown with narrowing" - in four places. Same MCP server configured three times in three JSON schemas. Same code-reviewer agent described twice with different frontmatter. Same deployment command in two directories. Then someone updated unknown to never for a specific case in CLAUDE.md only. Cursor still suggested unknown. Copilot agreed with neither. We spent a standup figuring out which AI was "right." The problem wasn't rules alone. It was the entire config surface: rules, agents, skills, commands, MCP servers, hooks, permissions, and ignore files - all duplicated per tool, all drifting independently. What I tried first I looked for existing tools that solve this. The most popular one in this space has the right model: one canonical source, generate per-tool configs. I used it for a few months. But I kept hitting gaps. Cross-references between files didn't get rewritten on generate, so an agent linking to a skill produced broken paths in every target. Activation semantics got inverted across tool dialects - a manual-only rule became always-on after translation. Hook configs got generated but the scripts they referenced didn't follow. Permissions weren't modeled as a feature at all. And every new AI coding tool that shipped needed a PR to the maintainer's repo — some requests sat open for over a year. These aren't bugs. They're architectural limits that compound once you grow past flat rule syncing into the full config surface: agents, skills with supporting files, hooks with scripts, permissions, MCP servers with tool-specific schemas. The pattern You already use this pattern elsewhere: package.json → package-lock.json Dockerfile → image *.proto → client SDKs Apply it to AI configs: One canonical directory describes rules, commands, agents, skills, MCP, hooks, ignore, and permissions in a tool-agnostic way. A generator projects them into each tool's native format. An importer does the reverse, so you can adopt without rewriting existing configs. A lock file detects drift in CI. The interesting work is in the link rewriting, the round-trip story, and getting the full feature surface (not just rules) to project correctly across 12 tools. What I built agentsmesh implements this pattern. Here's the canonical directory and what it generates: .agentsmesh/ Generated output (Claude Code): ├── rules/ ├── CLAUDE.md │ ├── _root.md ├── .claude/ │ └──…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.