← Back to context

Comment by hedgehog

20 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.

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.