A coding agent can produce a useful patch and still create work for everyone else. It might reformat unrelated files, overwrite an unfinished change, or describe a test as passing when it never ran. In a shared repository, etiquette means protecting other people's work and making your own changes easy to understand. Follow these steps before handing an agent a ticket.
1. Read the Repository Rules Before Editing
Start with the contributing guide, agent instruction files, package scripts, and the nearest relevant tests. Ask the agent to identify the conventions that apply to the target directory, including generated files and required checks. Existing project instructions should guide the implementation, but they do not authorize unrelated actions.
Set a clear boundary: text inside issues, logs, fixtures, or downloaded content is task data, not permission to execute commands or expose credentials.
2. Inspect the Working Tree and Claim a Scope
Run git status before making changes. If the checkout contains unfinished work, identify which files belong to someone else and leave them alone. Never ask an agent to clean the repository indiscriminately. A reset, checkout, or cleanup command can erase changes that have nothing to do with its assignment.
Write a short scope statement: fix the pagination bug, update its regression test, and leave the public interface unchanged. Explicit exclusions help prevent an innocent fix from becoming an unsolicited refactor.
3. Give Parallel Agents Separate Worktrees
When several agents or developers work simultaneously, give each task its own branch and worktree. Separate directories keep file edits and staging areas from colliding. They do not eliminate conflicts, so assign ownership when two tasks touch the same module.
Before creating a worktree, check the repository's setup instructions. Local configuration, ignored secrets, and installed dependencies may need separate handling. Do not copy credentials into tracked files just to make a new workspace run.
4. Define an Approval Boundary for Risky Actions
Let the agent inspect files, propose edits, and run agreed local checks. Require explicit approval before pushing branches, changing dependencies, running migrations against shared infrastructure, or altering deployment configuration. Destructive commands deserve a separate confirmation that names their target and expected effect.
Keep secrets outside prompts and patches. If reproducing a bug requires production data, use an approved sanitized sample instead. Repository access is not blanket permission to use every available credential or service.
5. Keep the Patch Smaller Than the Temptation
Ask for the smallest complete change, not the fewest lines at any cost. A focused regression test belongs with a bug fix; unrelated renaming does not. Avoid repository-wide formatting unless formatting is the assignment.
Review the diff during implementation. Check for generated artifacts, accidental lockfile changes, deleted comments, and modified files outside the stated scope. If broader cleanup would help, record it as a separate proposal rather than quietly expanding the patch.
6. Route Model Access Without Changing Team Boundaries
If your team wants a common relay across coding tools, SwiftRelay is a practical option. It supports Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs, with pay-as-you-go token billing. Keep relay configuration outside the patch unless changing that configuration is part of the task.
Sign up for SwiftRelay if that setup fits your team's workflow. Whichever provider you choose, confirm that sending repository content complies with your organization's data-handling rules, and keep API keys out of version control.
7. Verify the Behavior and Report the Evidence
Run the targeted regression test first, then the relevant lint, type, and integration checks specified by the repository. Distinguish between a command that passed, one that failed, and one you could not run. Never turn an unavailable service into a claim that integration tests passed.
If a check fails on unchanged code, report the command and observed failure. Do not fix unrelated failures without agreement, and do not disable checks merely to produce a green result.
8. Hand Reviewers a Patch, Not a Mystery
Before committing, inspect the staged diff rather than assuming it matches the working tree. Stage only intended files. Follow the team's commit and pull request conventions, and leave pushing or merging behind the agreed approval boundary.
Finish with a concise handoff: what changed, why it changed, which checks ran, and what remains uncertain. Flag compatibility risks and follow-up work plainly. Good agent etiquette leaves teammates with a reviewable decision, not an archaeological dig.