Contributing Guide
Relevant source files
The following files were used as context for generating this wiki page:
This guide outlines the processes for contributing to the Claude SDK for Go. It covers environment setup, code modification, testing, and security reporting. The SDK is largely a generated project, which influences how code should be added or modified to ensure persistence across generation cycles.
Environment Setup and Workflow
To begin contributing, developers must set up a local Go environment (version 1.22+) and utilize the provided automation scripts to ensure code quality and consistency.
Initialization and Quality Control
The project provides several scripts in the scripts/ directory to manage the development lifecycle.
| Script | Description |
|---|---|
./scripts/bootstrap | Installs all required dependencies and builds the SDK. |
./scripts/lint | Runs linting tools to ensure code style compliance. |
./scripts/format | Uses the standard gofmt code formatter. |
./scripts/test | Executes the test suite. |
./scripts/mock | Sets up a mock server against the OpenAPI spec for testing. |
Sources: CONTRIBUTING.md:9-15, CONTRIBUTING.md:43-47, README.md:53
Dependency Management
When working on the SDK from source in another local project, developers should use the Go replace directive to point to the local repository path.
$ go mod edit -replace github.com/anthropics/anthropic-sdk-go=/path/to/anthropic-sdk-go
Sources: CONTRIBUTING.md:32-34, scripts/utils/upload-artifact.sh:42
Modifying and Adding Code
The architecture of the SDK is primarily based on code generation from an OpenAPI specification. This requires a specific approach to manual modifications.
Generated vs. Manual Code
- Generated Code: Most of the SDK is generated. While manual modifications to generated files are persisted between generations, they may lead to merge conflicts during subsequent generator runs.
- Manual Directories: The
lib/andexamples/directories are never modified by the generator. These are the safest locations for manual additions.
Sources: CONTRIBUTING.md:19-24
Adding Examples
New functionality or usage patterns should be demonstrated by adding files to the examples/ directory.
Developers are encouraged to add new examples to showcase features like file uploads, streaming, or tool usage.
Sources: CONTRIBUTING.md:26-30, examples/file-upload/main.go
Testing Procedures
The project utilizes automated tests and mock servers to validate API interactions.
Mock Server Integration
Most tests require a running mock server that adheres to the OpenAPI specification. This is handled by the steady mock server.
Test Implementation
Tests are typically located in files appended with _test.go and use standard Go testing patterns. They often check for base URL overrides via the TEST_API_BASE_URL environment variable.
Sources: betamessage_test.go:18-22, usage_test.go:15-18
Releases and Documentation
Release Management
The project uses release-please for automated versioning and changelog generation. PR titles must follow specific patterns (e.g., release: ${version}) to be recognized.
| Change Type | Section in Changelog |
|---|---|
feat | Features |
fix | Bug Fixes |
perf | Performance Improvements |
docs | Documentation |
refactor | Refactors |
Sources: release-please-config.json:15-58
Documentation Contributions
The primary documentation is hosted at platform.claude.com. To suggest changes to the documentation, contributors are instructed to open an issue in the repository.
Sources: CONTRIBUTING.md:3-5, README.md:15
Security Policy
Security issues should not be reported via public GitHub issues.
- SDK Vulnerabilities: Contact Stainless Software at
security@stainless.com. - Anthropic Service Issues: Contact
support@anthropic.comor follow Anthropic's specific security guidelines. - Disclosure: Allow reasonable time for investigation before making any information public.
Sources: SECURITY.md:5-18
Summary
Contributing to the Anthropic Go SDK involves navigating a hybrid environment of generated and manual code. By utilizing the provided scripts/ for environment management, following the release-please convention for commits, and ensuring all changes are validated against the mock server, contributors can effectively maintain and extend the SDK while minimizing integration conflicts.