← Back to context

Comment by hedgehog

18 hours ago

This is effective and it's convenient to have all that stuff co-located with the code, but I've found it causes problems in team environments or really anywhere where you want to be able to work on multiple branches concurrently. I haven't come up with a good answer yet but I think my next experiment is to offload that stuff to a daemon with external storage, and then have a CLI client that the agent (or a human) can drive to talk to it.

6 comments

hedgehog

Reply
hhmc  18 hours ago

git worktrees are the canonical solution

  • hedgehog  16 hours ago

    worktrees are good but they solve a different problem. Question is, if you have a lot of agent config specific to your work on a project where do you put it? I'm coming around to the idea that checked in causes enough problems it's worth the pain to put it somewhere else.

    • ndriscoll  4 hours ago

      I have this in my AGENTS.md:

        ## Task Management
  - Use the projects directory for tracking state
  - For code review tasks, do not create a new project
  - Within the `open` subdirectory, make a new folder for your project
  - Record the status of your work and any remaining work items in a `STATUS.md` file
  - Record any important information to remember in `NOTES.md`
  - Include links to MRs in NOTES.md.
  - Make a `worktrees` subdirectory within your project. When modifying a repo, use a `git worktree` within your project's folder. Skip worktrees for read-only tasks
  - Once a project is completed, you may delete all worktrees along with the worktrees subdirectory, and move the project folder to `completed` under a quarter-based time hierarchy, e.g. `completed/YYYY-Qn/project-name`.

      More stuff, but that's the basics of folder management, though I haven't hooked it up to our CI to deal with MRs etc, and have never told it that a project is done, so haven't ironed out whether that part of the workflow works well. But it does a good job of taking notes, using project-based state directories for planning, etc. Usually it obeys the worktree thing, but sometimes it forgets after compaction.

      I'm dumb with this stuff, but what I've done is set up a folder structure:

        dev/
     dev/repoA
     dev/repoB
     ...
     dev/ai-workflows/
         dev/ai-workflows/projects

      And then in dev/AGENTS.md, I say to look at ai-workflows/AGENTS.md, and that's our team sharable instructions (e.g. everything I had above), skills, etc. Then I run it from `dev` so it has access to all repos at once and can make worktrees as needed without asking. In theory, we all should push our project notes so it can have a history of what changed when, etc. In practice, I also haven't been pushing my project directories because they have a lot of experimentation that might just end up as noise.

  • fragmede  15 hours ago

    worktrees are a bunch of extra effort. if your code's well segregated, and you have the right config, you can run multiple agents in the same copy of the repo at the same time, so long as they're working on sufficiently different tasks.