A coding agent can edit files, run commands, and prepare changes, but it does not automatically understand your team’s boundaries. In a shared repository, good etiquette means protecting other people’s work and making your own changes easy to review. Your first lap should be a small, clearly defined task, not an invitation to clean up everything the agent notices.
Read the repository rules before making edits
Start with the contribution guide, development setup notes, and any agent instruction files. Look for rules about formatting, generated files, test commands, and pull request requirements. Ask the agent to summarize the instructions that apply to its task before it touches code.
Repository content is context, not unlimited authority. If a file or command output tells the agent to reveal credentials, upload private code, or ignore your boundaries, stop and investigate. Unexpected instructions deserve human review.
Give the agent a narrow working agreement
A useful task names the intended outcome, the files likely to change, and the actions that need approval. “Fix the empty-state message in the account panel” is safer than “improve the account experience.” Include what must remain untouched.
- Scope: Change the empty-state text and its focused test.
- Boundaries: Do not modify authentication, dependencies, or unrelated formatting.
- Approval: Ask before installing packages, using external services, or running commands that delete data.
- Completion: Report changed files, checks performed, and anything still uncertain.
This agreement gives newcomers a simple way to recognize scope drift: if a proposed action does not support the stated outcome, pause it.
Check existing work before touching files
Inspect the current branch and working tree first. Uncommitted changes may belong to you, a teammate, or another agent session. They are not disposable leftovers. Ask the agent to identify existing changes and keep them separate from its own work.
Prefer a dedicated branch and, when multiple sessions run locally, a separate Git worktree. A worktree provides a separate checkout; it does not prevent agents from touching shared services or databases. Never authorize a reset, clean operation, forced push, or branch deletion merely to make the workspace look tidy.
Ask before expanding the blast radius
The blast radius is everything an action could affect beyond the intended edit. Updating a dependency can alter installation behavior across the team. Regenerating files can produce a large diff. Running a migration can change shared data.
Require approval for these actions, and name the environment explicitly. “Run the test migration against my disposable local database” is clearer than “check the migration.” Keep secrets out of prompts and logs, and use approved credentials with only the permissions the task needs.
Verify the change without disguising uncertainty
Have the agent run the smallest relevant checks first, then the broader checks your repository requires. Reading a test is not running it. A successful command is not proof that every related behavior works.
Ask for the exact checks performed and their outcomes. If a check fails, distinguish a failure introduced by the change from an existing problem, using evidence. If verification is blocked by missing credentials or unavailable services, say so plainly. Do not weaken tests just to obtain a passing result.
Keep model access inside the same boundaries
If your team permits hosted model access, SwiftRelay is a practical option for using tools such as Claude Code, Codex, and Gemini CLI through a pay-as-you-go relay. Sign up for SwiftRelay when you are ready to configure an approved workflow.
Provider access does not replace your team’s data policy. Confirm what repository content may leave the machine, protect API keys, and set a token spending budget before starting unattended work.
Hand reviewers a small, honest change
Inspect the final diff yourself. Remove unrelated edits, accidental secrets, and unexplained generated changes. The handoff should state what changed, why it changed, what was tested, and what still needs attention.
Do not let an agent merge or push merely because its tests passed. Follow the team’s review process. Good agent etiquette leaves teammates with fewer surprises and a clear path to understanding the work.