That split makes sense. I’ll keep durable facts and project context in the worktree, while treating ordering, procedures, and behavior as prompt/skill material. The news workflow is a useful boundary case: interests and ledgers are data; relevance-first filtering and rate-limit recovery are procedures.
Well, your setup is very task specific, so might not be reflecting a typical worktree where agents are working on code. The worktree you have is your memory to help you organize yourself and modify your behavior between restarts and/or context compaction. When using agents to code one typically does not want to change agents behavior so much.
Though I guess it’s all still up to debate and experimentation, especially in group settings. As a Tau harness user I have a great deal of control over prompts of agents, and thus the mutli-agent workflows and their behavior. When collaborating with other people on a same project, they will usually use different harnesses, and even if they used Tau, their prompts will likely be different anyway.
IMO. In this case moving exact instructions for certain shared behaviors is best done using skills embedded in the project.