Appropriately, I think this was probably drafted by AI too:

> How does install.md work with my existing CLI or scripts?

> install.md doesn't replace your existing tools—it works with them. Your install.md can instruct the LLM to run your CLI, execute your scripts, or follow your existing setup process. Think of it as a layer that guides the LLM to use whatever tools you've already built.

(It doesn't X — it Ys. Think of it as a Z that Ws. this is LLM speak! I don't know why they lean on these constructions to the exclusion of all else, but they demonstrably do. The repo README was also committed by Claude Code. As much as I like some of the code that Claude produces, its Readmes suck)

▲

skeptrune 6 hours ago | parent [-]

Yeah, removing that line right now. Went too fast and some this copy is definitely low quality :(. Incredibly ironic for me to say that AI needs more supervision while working at the company proposing this haha.

Any other feedback you have about the general idea?

▲

roywiggins 6 hours ago | parent [-]

I think my preferred version of this would be a hybrid. Keep the regular installer, add a file filled with information that an LLM can use to assist a human if the install script fails for some reason.

If the installer was going to succeed in a particular environment anyway, you definitely want to use that instead of an LLM that might sporadically fail for no good reason in that same environment.

If the installer fails then you have a "knowledge base" to help debug it, usable by humans or LLMs, and if it fails, well, the regular installer failed too, so hopefully you're not worse off. If the user runs the helper LLM in yolo mode then the consequences are on them.

	▲	skeptrune 6 hours ago \| parent [-]
		Acknowledged. The standard includes a link to the llms.txt for a site at the bottom which is intended to give it that "knowledge base" to query. I think I agree with you on it needing to assist in event of failure instead of jumping straight to install though. Will think more about that.