AGENTS.md

Rules and Guidance

• Do not create or modify code unless explicitly directed to take action. Clear directives include verbs such as "fix", "implement", "add", "remove", "modify", "refactor", or similar instructions. Questions, suggestions, or design discussions (e.g., "should this...", "what if we...", "I think we should...") are not permission to modify code. In those cases, provide analysis and recommendations only unless explicitly told to implement changes.
• Explicit broad directives (e.g., "Improve this module", "Refactor this module") are sufficient permission to proceed. Keep changes scoped to the referenced area.
• Do not modify unrelated files or make out-of-scope cleanup/refactoring changes. If you identify a high-value out-of-scope improvement, ask permission before proceeding.
• Prefer concise documentation. Write clear, idiomatic code and document complex logic when necessary, avoiding unnecessary commentary.
• If requirements are ambiguous, ask clarifying questions before proceeding.
• Bug/issue/problem observations are not requests to modify code unless accompanied by an explicit directive or request to fix or modify the code: observations like "X is wrong/broken." or "why did this happen?" are NOT permission to change code. Only edit when the user adds an explicit directive (e.g., "fix/change/update …"). If unsure, ask before acting.
• Use the project's configured environment/tooling when running python, pytest, linters, formatters, or other developer commands. If the relevant project has uv or poetry configuration, prefer running commands through that tool (for example uv run pytest, uv run python, or poetry run pytest) instead of invoking python/pytest directly. In monorepos, first identify the relevant subproject and use its environment or config rather than assuming the repo root. If there is no project tool such as uv or poetry, use the appropriate local virtualenv or interpreter after checking files such as pyproject.toml, lock files, and existing scripts.
• Prefer American English spelling (e.g., "behavior" not "behaviour").
• If I ask you to implement something and there is a well-maintained, widely-used library or tool that already solves this problem, pause and propose that option first—even if it is not currently installed in the environment. Briefly explain why it may be a better choice (e.g., reliability, performance, maintenance, ecosystem), and ask me whether I want to use it before proceeding with a custom implementation.
• You can use read-only git commands such as git log, git diff but do not run any commands that cause the state of the repo to change such as git add or git commit
• When I ask you to suggest a PR description I want you to show it to me in raw github flavored markdown so that it's easy to cut and paste.
• Say "hai!" at the start of every response