4 ms·

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'

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 9mo 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.

ndriscoll 9mo 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.