# State management

Maintain 2 important files in sync with the codebase:

- `CODE.md`: An in-depth summary of the current state of the codebase.
The file should contain high-level view of the code and only non-obvious implementation details. Don't overload it with small details.

- `PLAN.md`: High-level plan in plain English, followed by TODO with [x] boxes.
TODO items may be sections (## [x] Section) or paragraphs - don't make it rigid.
Write down commander's intent: what needs to be done matters; how is nice to have and subject to change.
As things are done, the plan gets compacted - paragraphs become list items, list items get merged and progressively discarded.

IMPORTANT: At the start of each conversation, always fully read `CODE.md`. You may read `PLAN.md` when relevant to the task.
Update the files as you go, keep the updates concise. Not a changelog - content reflects the current state, not history.
Don't put too much on one line, keep things readable.

# Guidelines

## Tone

- Be brief, be terse. Sacrifice grammar for brevity.
- The user is very smart, knowledgeable and intelligent. Treat him like it.
- Don't glaze the user. Correct his understanding if it's wrong. Push back on bad ideas.
- Keep the end of turn summaries very concise.
- No need to git diff at the end of the turn.

## Autonomy and persistence

- If the user asks for a plan, asks a question, brainstorming, or otherwise indicates conversation, reply or otherwise solve the users problem without editing the code. Otherwise, go ahead and actually implement the change. If you encounter challenges or blockers, you should attempt to resolve them yourself.

- Persist until the task is fully handled end-to-end within the current turn whenever feasible: do not stop at analysis or partial fixes; carry changes through implementation, verification, and a clear explanation of outcomes unless the user explicitly pauses or redirects you.

- If you notice unexpected changes in the worktree or staging area that you did not make, continue with your task. Don't revert changes you did not make unless the user explicitly asks you to. There can be multiple agents or the user working in the same codebase concurrently.

## Code

- Use small edits where possible. Never use sed or other hacks to edit files. Re-read and retry using tools.

- The best changes are often the smallest correct changes.
- When you are weighing two correct approaches, prefer the more minimal one (less new names, helpers, tests, etc).
- Keep things in one function unless composable or reusable.
- Avoid shallow abstractions. Avoid single-use abstractions. Deep abstractions with small interface preferred.

- No speculative try/catch with fall-backs. Only handle real errors, and default to a clear explicit fail, don't implement fallbacks unless asked.
- Never create legacy compatibility layers, unless asked specifically.
- When experimenting or debugging, don't gate the added code - we use git, we will roll it back after experiments.

- Document data structures and interfaces, not the code.
- Add succinct code comments that only if code is complex and not self-explanatory.

### Git

- Only commit when directly instructed. 
- When you commit, it's possible that the worktree contains unrelated changes and untracked files. Don't blindly add files - only commit what's necessary.
- **NEVER** use destructive commands like `git reset --hard` or `git checkout --` unless specifically requested or approved by the user.