7 ms·
I don't know if this is feedback for Kiro per se or more feedback for this category of applications as a whole, but I've personally noticed that the biggest bar
by postalcoder 1y ago
I don't know if this is feedback for Kiro per se or more feedback for this category of applications as a whole, but I've personally noticed that the biggest barrier holding me back from giving an earnest look at new coding agents are the custom rules I've set up w/ my existing agents. I have extensively used Copilot, Continue, Cursor, Cline, Aider, Roo Code, and Claude Code. I've just finished porting my rules over to Claude Code and this is something I do not want to do again [even if it's as simple as dragging and dropping files].
Companies would benefit a lot by creating better onboarding flows that migrate users from other applications. It should either bring in the rules 1:1 or have an llm agent transform them into a format that works better for the agent.
- namanyayg 1y agoin the early days of building something like that, would love to talk for 10 minutes and get your advice if you have the time? I couldn't find your email but mine is in my profile.
- ffsm8 1y agoOr a proper standard like MCP was for agentic tool use, this time for context setup...
- chrisweekly 1y agoProblems w auth / security in MCP skeeve me out. For that reason, I really don't want to invest in workflows that depend on MCP and have steered clear. But I'd be grateful for well-informed comments / advice on that front. 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 https://github.com/davidkimai/Context-Engineering> ^ inspiring stuff
- NathanKP 1y agoYou will be happy to find out that Kiro is quite good at this! One of my favorite features is "Steering Rules". Kiro can help you write steering rules for your projects, and the steering rules that it auto generates are actually super great for large projects. You can see some examples of auto generated steering files here in one of my open source projects: https://github.com/kirodotdev/spirit-of-kiro/tree/main/.kiro/steering https://github.com/kirodotdev/spirit-of-kiro/tree/main/.kiro... 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.
- adastra22 1y ago“I really don’t want to do X” “Kirk is actually quite good at this: you just have to do X” “…”
- NathanKP 1y agoAt the prompt: "I have extensively used Copilot, Continue, Cursor, Cline, Aider, Roo Code, and Claude Code. I do not want to move my files over again for Kiro [even if it's as simple as dragging and dropping files]. Do it for me" Kiro will do it for you automatically.
- adastra22 1y agoAnd then you have two separate specifications of your intent, with the ongoing problems that causes. It’s not the same thing.
- NathanKP 1y agoYeah it would be nice if there was one way to specify the rules and intent, but you know how these things go: https://xkcd.com/927/ https://xkcd.com/927/ 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 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.
- helpfulContrib 1y agoPorting rules is one of the responsibilities of keeping them.
- 1y ago
- theshrike79 1y agoI just have a “neutral” guidance markdown setup written in a repo. 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
- touristtam 1y agoI don't add them as submodule but just symlink and ignore them globally so they never find their way into codebase; I have colleagues that frown upon using LLMs, and. I am not going to start a war over their preferences.
- theshrike79 1y agoThis is just for my personal projects. I noticed I was copy-pasting the same crap to claude/gemini/cursor/windsurf/whatever and figured out a git submodule would be the easiest way to have the latest set of rules in every project 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.
- re5i5tor 1y agoNot Kiro related, but do your Claude Code version of rules end up as CLAUDE.md files in various locations?
- postalcoder 1y agoso I started off by doing this - having a single claude.md file but in it putting references to paths to other instruction files. 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?
- sys13 1y agoAgents.md is at least used by both codex and GitHub copilot. VSCode has its own thing for instruction files and Claude.md is also its own thing :(
- nsonha 1y agoand opencode
- insane_dreamer 1y agoMy Claude.md is a symlink to agents.md.
- esafak 1y agoThere should be a standard rule format in a standard place, like ~/.config/llms/rules.md
- kaptainscarlet 1y ago.vibecodingrc sounds better?
- brulard 1y agothis. We need a common file for all these tools. It's not like they can not read the format of each other.
- brulard 1y agoThis comment gets downvoted a lot and I can not figure why. Is the idea that agentic AI solutions could use single common file for the directions misguided or did I put the message together wrong?
- yodon 1y ago> There should be a standard rule format 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.
- newman314 1y agoIt would sure be nice to have some standardized conventions around this. AGENTS.md etc. It seems insane to have to have multiple files/rules for essentially the same goals just for different tools.
- tln 1y agoThats the convention I am using. My CLAUDE.md and GEMINI.md both just say "See AGENTS.md".
- seunosewa 1y agoHow about: Creating a MCP server that all the agents are configured to retrieve the rules from?
- 0x457 1y agoThen you have to add a rule to every agent to tell it to use this tool.
- apwell23 1y ago> have an llm agent transform them into a format that works better for the agent. you can do this today though.
- efitz 1y agoAFAICT there is no “format” to agent rule files; it’s just text describing how you’d like the LLM to behave. Typically I’ve seen bullet lists. 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.