I like the distinction between the rules.md and memory as rules are general for the organization and memory specific for the project.
However, progress is currently a markdown file where the module, technical debt and recent activity is updated.
I think it would be better to make the tasks into separate files so a specific task can be updated.
The advantage is that you keep a record for specific task instead of the project as a whole.
When the tasks are files you can put them in a process folder with subfolders for phases.
An agent for a specific phase can pick up a task and have minimal instruction for doing the work in that phase, thus cutting down on the overhead.
There could be basic phases like ToDo, Doing, Done.
Where the agent never looks in the Done phase, only moves files there, and only picks up a task from ToDo if there is nothing in Doing.
A more elaborate Kanban lanes like Backlog, ToDo, In Progress, On hold, Testing, Done, Approved,
but the phases should be bases on the type of agents you have and the handoff between them.
So if you have an agent who writes a spec for a task or turns a feature in multiple tasks you have the processing and done lanes for that.
With these phases you can run specific agents in parallel without overwriting each other
or you could have a single agent who checks on tasks in the phase pipline an loads instructions according to that phase.
P.S. Having the progress in files instead of a system like Jira, Azure Devops or a workflow system makes it easy to check and exposes the state of the project to all who have access to the code. Those who have access to the code should probably know what is going on with the code.
I like the distinction between the rules.md and memory as rules are general for the organization and memory specific for the project.
However, progress is currently a markdown file where the module, technical debt and recent activity is updated.
I think it would be better to make the tasks into separate files so a specific task can be updated.
The advantage is that you keep a record for specific task instead of the project as a whole.
When the tasks are files you can put them in a process folder with subfolders for phases.
An agent for a specific phase can pick up a task and have minimal instruction for doing the work in that phase, thus cutting down on the overhead.
There could be basic phases like ToDo, Doing, Done.
Where the agent never looks in the Done phase, only moves files there, and only picks up a task from ToDo if there is nothing in Doing.
A more elaborate Kanban lanes like Backlog, ToDo, In Progress, On hold, Testing, Done, Approved,
but the phases should be bases on the type of agents you have and the handoff between them.
So if you have an agent who writes a spec for a task or turns a feature in multiple tasks you have the processing and done lanes for that.
With these phases you can run specific agents in parallel without overwriting each other
or you could have a single agent who checks on tasks in the phase pipline an loads instructions according to that phase.
P.S. Having the progress in files instead of a system like Jira, Azure Devops or a workflow system makes it easy to check and exposes the state of the project to all who have access to the code. Those who have access to the code should probably know what is going on with the code.