the one file that does the same (maybe code focused, easily adapted)

---

Only documentation to write is project.md and TODO.md do not write documentation anywhere else.

TODO.md: document gaps, tasks and progress, grouped by feature

project.md: document architecture, responsability map, features and the tribal knowledge needed to find things

Do not document code, method, classes.

STANDARD OPERATING PROCEDURES:

Beginning of task:

- read: goals.md tech.md project.md

- update TODO.md add step by step [ ] tasks under the # feature you will implement

During execution of task:

- perform the task step by step, delegate if possible to sub tasks or sub agents

- log with [x] the work performed in TODO.md as you go

End of task:

- remove completed features from the TODO.md

- maintain project.md

Does this not result in subagents not logging their work?

I prefer the orchestrator to have a say, based on the answer of the sub agent

How does the subagent know what kind of notes to take? Does fhe orchestrator just discard them or summarize itself?

I find this interaction is where my subagent ideas explode (not transferring enough data up and down)

	▲	avereveard 2 days ago \| parent [-]
		most subagent tool have in the tool the sub agent calls to notify completion the message to return and a good documentation about how to return things, so the orchesrtator can orchestrate. the harness that don't have that mechanism can have it augmented by prompt roo code has a good harness for that (but terrible default prompts for the agents), kiro does that well too, gemini has a few misses as it just send off things without really caring of returns by default (albeit very model dependent), meanwhile jules using the same models has a good harness with a good feedback loop.