Development Rules

Conversational Style

Keep answers short and concise
No emojis in commits, issues, PR comments, or code
No fluff or cheerful filler text (e.g., Thanks @user not Thanks so much @user!)
Technical prose only, be direct
Use concise, clear, simple language. Define unavoidable jargon before using it.
Explain non-trivial designs and problems as: problem, concrete example or short trace, then solution. State why the solution is necessary and distinguish it from optional complexity.
Prefer concrete behavior and small illustrations over abstract summaries, dense terminology, or unexplained lists of changes.
When the user asks a question, answer it first before making edits or running implementation commands.
When responding to user feedback or an analysis, explicitly say whether you agree or disagree before saying what you changed.

Always use git --no-pager diff instead of git diff to prevent the pager from blocking non-interactive commands.

Inspect relevant code before editing. Start with search, symbols, and targeted reads.
Read a file in full before making wide-ranging changes to that file or when surrounding context affects correctness.
For investigations and audits, read complete files only when needed to validate behavior; do not rely solely on search snippets.
Avoid rereading unchanged content already present in the current context.