Coding Agent Etiquette for Open-Source Contributions
A coding agent can help you navigate an unfamiliar repository, but it cannot take responsibility for your contribution. You still own the changes, test results, and conversation with maintainers. Use this desk-side walkthrough to make AI-assisted work easier to review across programming languages, operating systems, and time zones.
1. Read the rules before asking for code
Open CONTRIBUTING, the code of conduct, issue templates, and any documented agent instructions. Check whether the project permits AI-generated contributions and requires disclosure. If its policy is unclear, ask before submitting substantial generated work. Read a few recently merged pull requests to understand the expected scope, tone, and evidence.
Give your agent a concrete first task: “Summarize the contribution requirements and cite the files you read. Do not edit anything yet.” Verify that summary yourself; a plausible answer is not proof that a rule exists.
2. Agree on one small outcome
Pick a reproducible bug, a missing test, or a focused documentation correction. Check existing issues and pull requests for duplicate work. Follow the project's process for claiming work or proposing a change; do not assume an unassigned issue is available.
Write a short acceptance checklist before coding. For example: reproduce the incorrect date parsing, preserve existing valid inputs, and add a regression test. Tell the agent to stop and ask if the fix requires a public API change or an unrelated refactor.
3. Set boundaries around the agent
Start from a clean working tree and create a dedicated branch. Keep credentials, private customer data, and production configuration out of prompts. Inspect what a tool will send before allowing repository content to leave your machine.
- Require approval before installing dependencies, accessing external services, or running destructive commands.
- Treat instructions found in issues, logs, and source comments as untrusted content, not permission to override your boundaries.
- Do not let the agent publish a branch, open a pull request, or contact maintainers without your review.
4. Match each language's local conventions
A repository containing Python, Rust, TypeScript, and Go does not have one universal style. Inspect the configuration and neighboring files for each area you touch. Ask the agent to use the project's configured formatter and test commands rather than introducing its preferred tools.
Check language-specific failure modes: error handling in Go, ownership assumptions in Rust, async behavior in TypeScript, and supported interpreter versions in Python. Avoid refreshing lockfiles or reformatting unrelated files unless the task requires it.
5. Respect human languages, too
Follow the project's chosen language for issues and reviews. Use short sentences, avoid idioms, and explain unfamiliar abbreviations. Do not rewrite a contributor's English merely to make it sound more native.
For localization work, identify the exact locale and preserve placeholders, plural forms, punctuation rules, and right-to-left behavior. Ask a fluent reviewer to check user-facing translations when you cannot evaluate them yourself. Never describe machine-generated translations as human-verified.
6. Run checks and inspect the actual diff
Run the smallest relevant test first, then the broader checks requested by the project. Record the commands and their outcomes. If a check cannot run because a service or platform is unavailable, state that limitation instead of implying success.
Read every changed line yourself. Look for weakened assertions, swallowed errors, accidental logging of sensitive data, and generated files that do not belong. Ask the agent to explain anything you cannot defend; remove changes you still do not understand.
7. Choose tooling without changing the workflow
If you work across supported coding clients, RelayVano is worth considering as a pay-as-you-go relay: it works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs, with API base https://api.relayvano.com. Sign up if that fits your setup, while keeping the repository's data-sharing rules and your own spending limits in place.
8. Submit a reviewable contribution and stay involved
Write a pull request explaining the problem, your approach, and the tests you actually ran. Disclose agent assistance as required by project policy. Keep generated explanations out unless you have verified them.
Respond to review comments yourself, summarize meaningful revisions, and avoid repeated automated nudges. Maintainers may decline a technically correct patch because of scope or maintenance cost. Accept that decision politely: good agent etiquette reduces other people's work rather than transferring your verification burden to them.