One agent standard that causes me pain: AGENTS.md / CLAUDE.md.
I have multiple machines (personal laptop, work laptop, server) and runtimes (Claude Code, Codex, Pi) which share common instructions, but also have special cases for each runtime or machine.
For instance, I have a section that’s common across all my agents that goes something like this: “Do not co-sign commits with an AI identity; do not add backwards compatibility if you were not asked to” .
For Pi I have a special case: “Use background task tool proactively for in-scope commands expected to run for long”.
In my server I have a section on how to use the credential proxy (which I don’t have in my other profiles).
So I made this little tool ‘mdmanager’ that helps me manage and deploy the .md files with reusable Markdown sections (like “agent-common”, “pi-common”) and profiles (“vps”, “laptop”)
How it works: you tell your coding agent to run “mdmanager docs start” and it guides you through the setup. You can then open the TUI to see the diff and inspect what gets loaded into the context. The TUI is read-only. To modify and apply, you talk to your agent (it has access to the docs via the CLI)
One feature that I use often is the “Context” section in the TUI.
Open the TUI from inside the repo, and you can see what instructions get loaded into context in one Markdown page, including global and project level *.md files that are in scope.
Right now it supports Claude Code, Codex, Pi, and Cursor. Feedback and contributions are most welcome.
The tool is more than templating and automation. It adds a workflow for inspecting and composing the instructions.
The TUI and the docs understand how each coding agent runtime loads instructions into context (they all have nuanced differences) including local
overrides, or what gets prioritised in case there is conflict (for instance, Pi accepts both CLAUDE.md and AGENTS.md).
Your agent can load the docs to understand nuances and help you manage how you want instructions to get loaded. You can use the TUI to render the concatenated instructions as they are loaded into your agent.
So yes, templating could be replaced with smth like Ansible, but the tool solves a bit more than just that.
I can, and do, do all that with ansible in my homelab setup. It's a cognative dissonance to downplay alternatives to make your features somehow unique. No LLMs are needed for this, if I were you, I would ask an agent to implement this in ansible just to see
Ansible can of course handle the templating and deployment. Not arguing that.
mdmanager packages runtime-specific discovery, reusable Sections and Profiles, an instruction-focused TUI, and bundled CLI docs into something you can install and use.
You could build that with Ansible too, but the interface, domain rules, documentation, and maintenance are part of what you’d be building. Packaging all the nuances of 4 runtimes in was a lot of work.
If your existing setup already gives you everything you need, great. You don’t need this.
That doesn’t make a dedicated tool redundant for everyone else.
“Ansible can do that” is a reasonable implementation suggestion. Taken it too far then “Python can do that” becomes an objection to everything posted on HN.
And no LLM is required for discovery, rendering, or deployment. Using an agent to edit the configuration is a workflow choice.
One agent standard that causes me pain: AGENTS.md / CLAUDE.md.
I have multiple machines (personal laptop, work laptop, server) and runtimes (Claude Code, Codex, Pi) which share common instructions, but also have special cases for each runtime or machine.
For instance, I have a section that’s common across all my agents that goes something like this: “Do not co-sign commits with an AI identity; do not add backwards compatibility if you were not asked to” .
For Pi I have a special case: “Use background task tool proactively for in-scope commands expected to run for long”.
In my server I have a section on how to use the credential proxy (which I don’t have in my other profiles).
So I made this little tool ‘mdmanager’ that helps me manage and deploy the .md files with reusable Markdown sections (like “agent-common”, “pi-common”) and profiles (“vps”, “laptop”)
How it works: you tell your coding agent to run “mdmanager docs start” and it guides you through the setup. You can then open the TUI to see the diff and inspect what gets loaded into the context. The TUI is read-only. To modify and apply, you talk to your agent (it has access to the docs via the CLI)
One feature that I use often is the “Context” section in the TUI.
Open the TUI from inside the repo, and you can see what instructions get loaded into context in one Markdown page, including global and project level *.md files that are in scope.
Right now it supports Claude Code, Codex, Pi, and Cursor. Feedback and contributions are most welcome.
Why a single purpose tool versus something like Ansible?
The tool is more than templating and automation. It adds a workflow for inspecting and composing the instructions.
The TUI and the docs understand how each coding agent runtime loads instructions into context (they all have nuanced differences) including local overrides, or what gets prioritised in case there is conflict (for instance, Pi accepts both CLAUDE.md and AGENTS.md).
Your agent can load the docs to understand nuances and help you manage how you want instructions to get loaded. You can use the TUI to render the concatenated instructions as they are loaded into your agent.
So yes, templating could be replaced with smth like Ansible, but the tool solves a bit more than just that.
Thanks for the question!
I can, and do, do all that with ansible in my homelab setup. It's a cognative dissonance to downplay alternatives to make your features somehow unique. No LLMs are needed for this, if I were you, I would ask an agent to implement this in ansible just to see
Ansible can of course handle the templating and deployment. Not arguing that.
mdmanager packages runtime-specific discovery, reusable Sections and Profiles, an instruction-focused TUI, and bundled CLI docs into something you can install and use.
You could build that with Ansible too, but the interface, domain rules, documentation, and maintenance are part of what you’d be building. Packaging all the nuances of 4 runtimes in was a lot of work.
If your existing setup already gives you everything you need, great. You don’t need this. That doesn’t make a dedicated tool redundant for everyone else.
“Ansible can do that” is a reasonable implementation suggestion. Taken it too far then “Python can do that” becomes an objection to everything posted on HN.
And no LLM is required for discovery, rendering, or deployment. Using an agent to edit the configuration is a workflow choice.