Agent Conduct

How agents should reason, check in, and manage project knowledge when working in this project.

Session Start

Read, confirm, then wait

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.


Board detail files are not first-layer

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.

Reasoning and Check-ins

The core rule

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.


Always interrupt when

  • Reasoning has gone on for ~1 000 tokens and no root cause is found.
  • Multiple hypotheses seem equally plausible.
  • The cause requires runtime information (console errors, network responses, live state) that cannot be determined statically.
  • The fix would require reading many more files without a clear lead.

When interrupting

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.


Only skip the interrupt when

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.

Knowledge and Memory

The workspace is the memory

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.


What goes where

  • Planned features and open items - outline
  • Session notes and what was built - history entry via the Update History action
  • Coding conventions and how-tos - a guide under guides/
  • Recurring procedures - an action under actions/

Be scope aware

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.

Writing Style

Use - not —

When writing workspace documents, use the hyphen/minus character - instead of the em dash —. This applies to prose, lists, and task descriptions.