Also these steering rules are just markdown files, so you can just drop your other rules files from other tools into the `.kiro/steering` directory, and they work as is.

“Kirk is actually quite good at this: you just have to do X”

“…”

Kiro will do it for you automatically.

In all seriousness, I'm sure this will become more standardized over time, in the same way that MCP has standardized tool use.

I've long been interested in something that can gather lightweight rules files from all your subdirectories as well, like a grandparent rule file that inherits and absorbs the rules of children modules that you have imported. Something kind of like this: https://github.com/ash-project/usage_rules

I think over time there will be more and more sources and entities that desire to preemptively provide some lightweight instructive steering content to guide their own use. But in the meantime we just have to deal with the standard proliferation until someone creates something amazing enough to suck everyone else in.

Was it built to only adhere to what is in .kiro folder?

We are a few months into widespread use of this class of technology. Now is a terrible time to introduce standards. Would be a small short term gain delivering huge long term pain.

My CLAUDE.md and GEMINI.md both just say "See AGENTS.md".

The idea of having a bunch of A100 GPU cycles needed to process the natural language equivalent of a file pointer makes me deeply sad about the current state of software development.

Creating a MCP server that all the agents are configured to retrieve the rules from?

Then I add it as a git submodule to my projects and tell whatever agents to look at @llm-shared/ and update its own rule file(s) accordingly

That way I can just add new stuff to llm-shared/, commit, push and other projects will get the same things. It also forces me to keep it generic so it fits every project.

Then I just tell whatever LLM to look into @llm-shared/ for instructions and refer to files there when needed instead of having them in the "main" context file.

As for a hypothetical new "context setup" protocol like you posit, I suspect it'd benefit from the "cognitive tools" ideas in this awesome paper / project: <https://github.com/davidkimai/Context-Engineering>

^ inspiring stuff

I found this approach to be quite poor from the standpoint of cloud seems to treat user instructions very differently than other agentic code assistants and I think it’s because their system prompt is so long. As a result, I’m getting some pretty poor adherence to my claude.md file and I’ve noticed that very rarely if ever have I seen it reverse the file to any of the nested paths.

So.. im going to try to refactor my files to keep it all in the same file, with some heavy “LOOK AT ME” prompt engineering.

How about you?

you can do this today though.

Some agents have multiple prompts that are used for different modes; I’ve typically seen this stored as JSON that is agent specific and wouldn’t necessarily apply to different agents.

The only agent specific thing I’ve ever included in a context file is referring to a specific tool. I probably could have abstracted that by describing it as “the tool that does X” or by just telling it to do the function that the tool does.