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.

ansible can do all of those things you are saying it cannot, it's a provisioning system, so your python analogy is more deflection than actual consideration of feedback, and honestly closer to what you have done, used a programming language to implement something that could be done in the tools we already use to provision systems in industry

it doesn't sound like you want feedback that challenges your assumptions, the point of sharing on HN should be to challenge your assumptions, because as the saying goes "no product survives first contact with users"

Point taken, I agree Ansible could have worked nicely for this tool. While I do think there's value in packaging the workflow into a ready-made tool.

I do appreciate the input, thanks!

Fair - some of the points in these examples will rot. What I think transfers are the failure modes: context rot, agents filling in decisions, whether a codebase is greppable. Those can turn into team principles, and you can only learn this through experimentation.

Author here. Thanks for the comment.

I did refer to some specific models, though a lot of these learnings are from experience over the past 6 months or so, and continue to generalize as frontier models improve.

Curious if there’s a specific point you feel is too detailed?

I’d agree Linus is an exceptional leader. And I don’t think most rules apply to him.

I’m working on “nah” [1] an agent hook guard that blocks catastrophic agent actions like filesystem destruction, secrets exfiltration, and git disasters.

All the agent hook guards I’ve seen can be easily removed by agents (and they often do so they can get going with the task). I made mine harder to remove, and I’m working on making it impossible.

I also made “nah” easily extensible. Just point your agent to the docs which ship with the CLI, and ask it to build a custom guard.

I’m working on strong Python and Typescript pseudo-interpreters so I can detect disasters in inline code with less false positives. Bash parser is already very strong.

This is a side-project that I want to be proud off. I spend a lot of time designing, not just coding.

[1] nahguard.ai

Love the vibe of the website!

Do I understand correctly that you scope least-privilege creds/tokens and pass those to the sandbox? I'd be curious to learn more

If an organization decides the engineering team should not be looking at code, that should be coupled with a mandate to figure out what good engineering looks like working that way - what constitutes a good contribution vs what's slop? How do we handle massive PRs? The problem is we are in the "messing around phase" of coding with clankers and have much to learn still

Working in the era of 200k context window meant I had to narrowly scope tasks to fit in the context window, forcing me to think about how to reduce complexity and naturally resulting in atomic work. 1M context windows and the promise that the latest models are "better at long running tasks" made me lazy in how I scope tasks and quality got worse. I now went back to narrow-scoping one session per task and zero compaction, trying not to go past 400k context window. If I end up with a long session, I was likely too ambitious and should have broken up the task.

Let's hope not all frontier AI assimilates these guardrails. It would be a shame for independent researchers and students.

I get a sense that I was click-baited by article's title with the classic trope of "X is all you need". This research is a solid contribution, but is far from all we need to understand grep vs semantic search in agent retrieval.