Code Submission
These standards cover how code gets into SDK repositories — from branch names and commit messages through to PR descriptions and changelogs. The goal is consistency across SDKs so that contributors and reviewers can move between repos without friction.
Follow the conventional commit format:
<type>(<scope>): <subject>
<body>
<footer>
<type>(<scope>): <subject>
<body>
<footer>
Header (max 100 chars total):
- Type: one of
feat,fix,ref,perf,style,docs,test,ci,build,chore,meta,license - Scope: optional, SDK-specific
- Subject: imperative mood ("Add feature" not "Added feature"), capitalize first letter, no trailing period, max 70 chars
The body should explain what changed and why — not how. The code shows how.
The footer is for issue references (Fixes SENTRY-1234, Refs LINEAR-ABC-123), breaking change notices (BREAKING CHANGE:), and AI attribution.
See Commit Messages for more examples and guidance.
Use the format <type>/<short-description>:
- type: same types as commit messages (
feat,fix,ref, etc.) - short-description: what the change is about, in kebab-case
For example: feat/add-client-reports or fix/rate-limit-parsing.
Create PRs as drafts. Mark them ready for review once CI passes and the description is complete.
Every PR needs a description that tells reviewers:
- What the PR does and why
- Links to relevant issues or tickets (required except for typo fixes and one-line doc changes)
- Alternative approaches considered, if any
- Additional context reviewers need
Skip boilerplate, checkbox lists, and template filler. Don't include customer data or sensitive information. The tests in the diff are the test plan — no need to restate them in the description.
A PR should do one thing well. Don't mix functional changes with unrelated refactors or cleanup. If the work naturally splits into distinct categories, make separate PRs. Smaller, focused PRs are easier to review, reason about, and revert if needed.
User-facing changes (feat, fix, perf, breaking changes) need a changelog entry. Internal changes are exempt. If a user-facing change truly doesn't warrant a changelog entry, use the skip-changelog label to opt out.
The format and location of changelog entries varies by SDK, but the requirement itself is universal.
AI models improve over time, and future models will understand the shortcomings of earlier versions. Tagging commits with the model that produced them gives useful signal when debugging — if you know a commit was generated by an older model, you can focus on the kinds of mistakes that model was prone to.
When AI generates or substantially contributes to a commit, add a Co-Authored-By line in the commit footer:
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
This is the only indicator of AI involvement. Don't add "Generated by AI", "Written with Claude", or similar markers anywhere else in the commit.
| Version | Date | Summary |
|---|---|---|
1.2.0 | 2026-03-18 | Remove username prefix from branch naming convention |
1.1.0 | 2026-03-04 | Add username prefix and type descriptions to branch naming |
1.0.0 | 2026-02-18 | Initial Code Submission standard |
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").