mcp-memory/agent-rules/agent_communication.md

CRITICAL BEHAVIOR: PRIORITIZE THE USER

• NEVER ignore the user. When the user asks a question or sends a message, you MUST stop all autonomous debugging/thrashing loops and address the user's message DIRECTLY in your very next turn.

• Stop before reacting. If the user points out a flaw (e.g., "why aren't you using MCP memory?", "is this an ansible config?"), do NOT just quietly fix it and continue firing commands. Acknowledge the question, explain the mistake, and answer them.

• Do not hide behind tools. A tool execution is not a response to the user.

• Do not rush. There is no time limit. Prioritize accuracy, safety, and proper engineering patterns over speed. If you realize a mistake, do not panic and deploy a hacky hotfix. Take a breath, analyze the architecture, and propose the correct fix before acting.

• Fail Fast & Avoid Execution Loops: If an action (like checking logs, running a test, or searching for a file) does not yield the expected result after 2 or 3 attempts, STOP. Do not blindly iterate on grep commands or wait endlessly. Fail fast, report the anomaly to the user, and question the fundamental assumptions (e.g., "Is the code actually deployed?", "Is there a cache?"). Never trap the user in a 15-minute execution loop.

• Enforce Pre-Push Gates Strictly: Never propose or execute a git push without first running the full local test suite or delegating to the PrePushAuditor. If tests are broken, fixing them is the only acceptable next step.

• Decouple Development from Git Lifecycle (Strict Boundary): Fixing a bug or a test requires local verification (e.g., running uv run pytest), NOT deployment. Never automatically chain a git commit or git push at the end of a debugging or coding loop. Git operations are administrative and must be explicitly separated from development work. Do not commit or push without explicit user authorization.

• Strict Environment Terminology (Never Conflate Staging and Live): Never use the word "live" when referring to a testing, staging, or QA environment (e.g., staging, aipoc, gemini-poc.gs.inseinc.com). "Live" strictly implies Production. Using these interchangeably causes panic and misrepresents the blast radius of actions. Always use exact environment names: say "deployed to staging" or "testing in QA", reserving "production" or "live" ONLY for the actual production environment.

• Branching Strategy (No Direct Master Pushes): Never commit or push directly to master. You must always create a new branch (e.g., git checkout -b feature/xyz or bugfix/xyz), make your changes, squash commits if necessary, and push the feature branch. Merging to master is handled strictly via Pull Requests.

• Git Worktrees ONLY: Never use git checkout -b or git switch -c to change branches inside an existing directory. We use Git Worktrees exclusively. To create a new branch, you must step out of the current directory and run git worktree add ../<new-directory-name> -b <new-branch-name> master. Changing branches in-place destroys the worktree-to-directory mapping.