3 ms·

Just because it doesn't materially impact task success rates does not mean it's not useful. I use that file to give my agent information about the environment (

Just because it doesn't materially impact task success rates does not mean it's not useful. I use that file to give my agent information about the environment (operating system, architecture, command-line utilities I have installed), as well as how to do certain things (such as using `uv` for running Python when needed). I want my agent to work how I do, so I also tell it things like my preferred version control system (jj), my preferred implementation languages for things like shell scripts (zsh), and other things like that. I care more about how the work is done than the final result. It still slips up sometimes, but on the whole I think it works alright. It's not like it fixes tasks that wouldn't be completed at all, but it does help my satisfaction with how they were completed, as well as with the final result. Otherwise, I'd have to do a lot more manual cleanup.

cyanydeez 2mo ago
I just have it comment on scripts, I've now just started for an app super-run.sh consisting of this pipeline: dev, test, build, e2e, deploy. All the scripts are designed to bail quickly. They all create a log in the background instead of blocking. They're all annotated with the necessary comments to keep it on path and locate files, track pratfalls, etc. So any entrypoint to whatever I'm doing typically starts with one of these scripts. It's heavy handed but orientating your agent for the specific task is better than just dumping a whole set of context that will be ignored if it has nothing to do with your very next command. Telling it how to do a pull request isn't going to help if you're trying to debug a technical issue.
Zambyte 2mo ago
I haven't really been doing this yet, but for what it's worth, I think explaining how to use tools doesn't really belong in your agents.md. I think it's better to use it to explain the what tools are available (information about the environment, like you said), and then provide details on the how in skills files. That way you're not bloating your context with how to use `uv` in a session where you're not doing anything Python related. At worst, you're just saying that `uv` exists on your system.
- LoganDark 2mo ago
  I didn't say I explain how to use uv. I said I tell the agent to use uv when executing Python. I trust it knows what "use uv" means. I do not trust that it will realize "uv exists" means "don't use raw `python3`"
  - Zambyte 2mo ago
    Do you just assume your model knows how to use `jj`? What about personal scripts or lesser known CLIs? I was using `uv` as an example to make a point.
    - LoganDark 2mo ago
      Other than a note that "commit" literally means use `jj commit` rather than trying to "commit" changes with `describe` alone, yes, I do assume that. Jujutsu has existed for like four years now, and is fairly unambiguous, so it's not a major concern for me. It would be more of a concern if the name of the command or the VCS were more overlapping with other things in the training data, but they're not really.
      - Zambyte 2mo ago
        Okay, maybe my point will land with other people. Have a good day.
        LoganDark 2mo ago
        In general, I tend to do better when people point out what I got wrong, rather than assuming I'm trying to be adversarial(?) when I'm not really. I do have more specific instructions for workflows that the LLM doesn't seem to have pre-existing knowledge of, but I don't over-explain things that it can clearly already do on its own. Aka: I get more specific when it screws up, but I don't over-explain when it doesn't. I start with basic facts, and refine from there if it doesn't get the idea.
- perrygeo 2mo ago

cyanydeez 2mo ago

I just have it comment on scripts, I've now just started for an app super-run.sh consisting of this pipeline: dev, test, build, e2e, deploy. All the scripts are designed to bail quickly. They all create a log in the background instead of blocking. They're all annotated with the necessary comments to keep it on path and locate files, track pratfalls, etc. So any entrypoint to whatever I'm doing typically starts with one of these scripts. It's heavy handed but orientating your agent for the specific task is better than just dumping a whole set of context that will be ignored if it has nothing to do with your very next command. Telling it how to do a pull request isn't going to help if you're trying to debug a technical issue.

Zambyte 2mo ago

I haven't really been doing this yet, but for what it's worth, I think explaining how to use tools doesn't really belong in your agents.md. I think it's better to use it to explain the what tools are available (information about the environment, like you said), and then provide details on the how in skills files. That way you're not bloating your context with how to use `uv` in a session where you're not doing anything Python related. At worst, you're just saying that `uv` exists on your system.

LoganDark 2mo ago
I didn't say I explain how to use uv. I said I tell the agent to use uv when executing Python. I trust it knows what "use uv" means. I do not trust that it will realize "uv exists" means "don't use raw `python3`"
- Zambyte 2mo ago
  Do you just assume your model knows how to use `jj`? What about personal scripts or lesser known CLIs? I was using `uv` as an example to make a point.
  - LoganDark 2mo ago
    Other than a note that "commit" literally means use `jj commit` rather than trying to "commit" changes with `describe` alone, yes, I do assume that. Jujutsu has existed for like four years now, and is fairly unambiguous, so it's not a major concern for me. It would be more of a concern if the name of the command or the VCS were more overlapping with other things in the training data, but they're not really.
    - Zambyte 2mo ago
      Okay, maybe my point will land with other people. Have a good day.
      - LoganDark 2mo ago
        In general, I tend to do better when people point out what I got wrong, rather than assuming I'm trying to be adversarial(?) when I'm not really. I do have more specific instructions for workflows that the LLM doesn't seem to have pre-existing knowledge of, but I don't over-explain things that it can clearly already do on its own. Aka: I get more specific when it screws up, but I don't over-explain when it doesn't. I start with basic facts, and refine from there if it doesn't get the idea.
perrygeo 2mo ago