一つのファイルから生成しても、指示のズレは止まらないThe author built a tool to generate all AI agent instruction files from a…

As AI coding assistants multiply, developers increasingly find themselves maintaining a separate instruction file for each tool, and keeping those files in sync has become its own maintenance burden. A recent blog post on Zenn documents one developer's attempt to solve this with a tool called agent-fanout, along with a candid account of why the approach, while functional, does not fully eliminate the problem.

The premise is straightforward. Each major AI coding agent reads its own configuration file: Anthropic's Claude Code looks for CLAUDE.md, Cursor uses rule files under .cursor/rules/*.mdc, and GitHub Copilot reads .github/copilot-instructions.md. When a team wants all of these agents to follow the same coding conventions, project context, and constraints, the naive solution is to copy the same content into each file. Copies drift. One file gets updated, the others lag behind, and the agents begin behaving inconsistently.

The author's response follows a familiar software engineering principle: eliminate the copies. Instead of maintaining several parallel documents, write a single AGENTS.md as the source of truth and generate the tool-specific files from it. AGENTS.md itself is an emerging convention intended to give AI agents a standard, human-readable place to find project instructions, and a growing number of tools recognize or can be adapted to it. The agent-fanout tool, published on GitHub at github.com/untactit/agent-fanout and run with a simple python3 agent_fanout.py invocation, reads the single source and writes out CLAUDE.md, the Cursor rule files, and the Copilot instructions file automatically.

By the author's account, the tool works as designed. Running the script produces the derived files, and the generation step behaves reliably. Yet the post's central argument is captured in a deliberately jarring pair of statements: it was built, it works, and it still does not solve the problem. The gap between a working generator and a solved problem is what the author sets out to examine, and it is a gap they say they only noticed after running the setup on real projects rather than in theory.

The core issue appears to be that instruction drift is not solely a file-synchronization problem. Generating identical text into multiple files guarantees that the files match, but it does not guarantee that each agent interprets or applies that text the same way. Different agents have different formatting expectations, different limits on how much instruction they will reliably follow, and different behaviors around precedence and context. Content that is optimal in AGENTS.md may need to be reshaped, not merely copied, to produce equivalent behavior in Claude, Cursor, and Copilot. In other words, the coverage that generation provides ends at the boundary of textual identity, while the drift that matters happens at the level of behavior.

This distinction is useful context for teams evaluating similar single-source strategies. The broader industry has been moving toward shared conventions precisely to reduce this kind of fragmentation, and AGENTS.md is one of several efforts to standardize how agents receive instructions. Tools that convert or fan out from a canonical file are a natural next step, and agent-fanout is an example of that pattern. But the report is a reminder that standardization at the file level does not automatically produce standardization at the behavior level.

For practitioners, the practical takeaways are modest but concrete. A single-source generator like agent-fanout can remove the mechanical toil of keeping several files consistent, and that alone may be worthwhile for teams juggling multiple assistants. It is less likely, based on this account, to serve as a complete answer to making every agent behave identically. Teams adopting the approach would likely still need to verify each agent's actual output, tune per-tool sections where behavior diverges, and treat generation as one layer of a larger process rather than a finished solution.

The post's value lies less in the tool itself than in its honesty about the limits of a tempting shortcut. The instinct to collapse duplicated configuration into one source is sound, and the tooling to do so is easy enough to build. What the author documents is the more subtle lesson that emerges only in real-world use: eliminating copies removes one class of drift