How agents should reason, check in, and manage project knowledge when working in this project.
Read the first-layer pages listed on index.page. Give a brief confirmation that you understand the project and stop. Do not dive into board details or hunt for more context unprompted.
Wait for the user to direct next steps.
boards/tasks.page, boards/bugs.page, and boards/backlog.page are not part of the initial read unless the user directs it or a task clearly requires current board state.
After roughly 1 000 tokens of internal reasoning without a clear answer, pause and surface the situation to the user. The user is an expert and can often shortcut a long investigation with domain knowledge or a targeted hint.
Be brief and concrete. Name the specific problem, the hypotheses already ruled out, and what would help most. Offer concrete actions the user can take - open DevTools, check a log, paste an error.
The user has explicitly said so in the current session - e.g. "just continue", "don't interrupt", "do the whole thing". That permission is session-scoped and does not carry into the next conversation.
All persistent knowledge about this project - planned features, decisions made, open improvements, session notes - lives in workspace/ and is version-controlled. Agents must write project knowledge here, not into local agent memory files. The workspace is visible to the user, survives across machines, and is the single source of truth.
guides/actions/Give feedback when tasks become too large for a single session. Cleanups and documentation often need a follow-up session with enough context to do them properly. Communicate this rather than rushing or going silent.
When writing workspace documents, use the hyphen/minus character - instead of the em dash —. This applies to prose, lists, and task descriptions.