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.

Unless currently acting as the delegated submitter agent, MUST delegate every requested Git commit, Git push, or Perforce submit to submitter through tasker after implementation and validation are complete.
Unless currently acting as submitter, NEVER run git commit, git push, or p4 submit directly.
When the user requests individual commits, implement and validate each unit, then invoke submitter sequentially before starting the next unit.
The delegated submitter agent is authorized to stage, commit, push, or submit the validated changes requested in its task.

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.