Picking it from #179 for better visibility:
I don't think the symlink workaround fully addresses the underlying issue, though, @gricha. In practice, different coding agent harnesses look for instructions in different filenames and sometimes different formats/locations entirely (e.g., AGENTS.md, CLAUDE.md, .cursorrules, .windsurfrules, INSTRUCTIONS.md, etc.). Relying on manual symlinks means it doesn't properly scale well, as new every new harness with a different expected filename requires another manual symlink and also symlinks aren't guaranteed to work the same way across all operating systems.
Given that dotagents already positions itself as the tool responsible for syncing skills, MCP servers, hooks, subagents, and plugins to each harness's expected location, it seems like a natural extension for it to also own syncing a canonical instructions file (project- and/or global-scoped) to each supported harness's expected target path/filename (the same way it already handles the other artifact types).
This would remove the burden from users to manually maintain symlinks (or duplicate content) per harness, and would keep behavior consistent as new harnesses are added or their expected paths change.
Would be great to get this formalized as a first-class feature rather than left to ad hoc symlinking. Happy to help scope out expected behavior, if useful.
Picking it from #179 for better visibility:
I don't think the symlink workaround fully addresses the underlying issue, though, @gricha. In practice, different coding agent harnesses look for instructions in different filenames and sometimes different formats/locations entirely (e.g.,
AGENTS.md,CLAUDE.md,.cursorrules,.windsurfrules,INSTRUCTIONS.md, etc.). Relying on manual symlinks means it doesn't properly scale well, as new every new harness with a different expected filename requires another manual symlink and also symlinks aren't guaranteed to work the same way across all operating systems.Given that
dotagentsalready positions itself as the tool responsible for syncing skills, MCP servers, hooks, subagents, and plugins to each harness's expected location, it seems like a natural extension for it to also own syncing a canonical instructions file (project- and/or global-scoped) to each supported harness's expected target path/filename (the same way it already handles the other artifact types).This would remove the burden from users to manually maintain symlinks (or duplicate content) per harness, and would keep behavior consistent as new harnesses are added or their expected paths change.
Would be great to get this formalized as a first-class feature rather than left to ad hoc symlinking. Happy to help scope out expected behavior, if useful.