-
Notifications
You must be signed in to change notification settings - Fork 167
docs(contribute): Add contributor guide #481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
459bb0a
c5bc12a
a049a8d
0c8103a
0a75cef
715b18f
219ea10
2f49e68
0c6d504
696d343
2c0049c
4ff1371
0aa8b32
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,54 +1,57 @@ | ||
| # Community Packages | ||
| # Community catalog | ||
|
|
||
| The Strands Agents SDK is built on community contributions that extend agent capabilities through custom tools and integrations. If you've built a useful extension for Strands Agents that solves a common problem or integrates with popular services, packaging it for distribution allows other developers to benefit from your work. | ||
| The Strands community has built tools and integrations for a variety of use cases. This catalog helps you discover what's available and find packages that solve your specific needs. | ||
|
|
||
| ## Creating A Package | ||
| Browse by category below to find tools, model providers, session managers, and platform integrations built by the community. | ||
|
|
||
| The first step to sharing your Strands component with the community is creating a Python package. Follow the [official Python packaging tutorial](https://packaging.python.org/en/latest/tutorials/packaging-projects/) for complete packaging guidance. The key steps are: | ||
| !!! info "Community maintained" | ||
| These packages are maintained by their authors, not the Strands team. Review packages before using them in production. Quality and support may vary. | ||
|
|
||
| - **Create a GitHub repository** - use the naming convention `strands-{thing}` for consistency with the ecosystem. | ||
| - **Add detailed documentation** - add a README with usage examples and API references. | ||
| - **Include thorough tests** - use unit tests to verify business logic and integration tests to validate the components works against one or more providers. Ensure proper code coverage. | ||
| ## Tools | ||
|
|
||
| [strands-clova](https://github.com/aidendef/strands-clova) is a community package that can serve as a good example. | ||
| Tools extend your agents with capabilities for specific services and platforms. Each package provides one or more tools you can add to your agents. | ||
|
|
||
| ## Publishing to PyPI | ||
| | Package | Description | | ||
| |---------|-------------| | ||
| | [strands-deepgram](./tools/strands-deepgram.md) | Deepgram speech-to-text | | ||
| | [strands-hubspot](./tools/strands-hubspot.md) | HubSpot CRM integration | | ||
| | [strands-teams](./tools/strands-teams.md) | Microsoft Teams | | ||
| | [strands-telegram](./tools/strands-telegram.md) | Telegram bot | | ||
| | [strands-telegram-listener](./tools/strands-telegram-listener.md) | Telegram listener | | ||
| | [UTCP](./tools/utcp.md) | Universal Tool Calling Protocol | | ||
|
|
||
| Once you have a package, you can then publish to PyPI to make it consumable to others. Publishing to PyPI allows users to install your package with pip. | ||
| ## Model providers | ||
|
|
||
| Best practices for publishing include: | ||
| Model providers add support for additional LLM services beyond the built-in providers. Use these to integrate with specialized or regional LLM platforms. | ||
|
|
||
| - **Configure GitHub workflows** - set up CI/CD to automatically publish releases to PyPI when you create new releases. | ||
| - **Follow semantic versioning** - use semver.org conventions for version numbering to help users understand the impact of updates. | ||
| | Package | Description | | ||
| |---------|-------------| | ||
| | [Cohere](./model-providers/cohere.md) | Cohere LLM | | ||
| | [CLOVA Studio](./model-providers/clova-studio.md) | Naver CLOVA Studio | | ||
| | [Fireworks AI](./model-providers/fireworksai.md) | Fireworks AI | | ||
| | [Nebius](./model-providers/nebius-token-factory.md) | Nebius Token Factory | | ||
|
|
||
| ## Getting Featured in Documentation | ||
| ## Session managers | ||
|
|
||
| Once your package is published to PyPI, you can request to have it featured in the Strands Agents documentation. Featured packages should provide clear utility to the community and meet high quality standards including comprehensive documentation, thorough testing, and reliable functionality. | ||
| Session managers provide alternative storage backends for conversation history. Use these when you need persistent, scalable, or distributed session storage. | ||
|
|
||
| See our [Get Featured](./get-featured.md) guide for step-by-step instructions on adding your package to the docs. | ||
| | Package | Description | | ||
| |---------|-------------| | ||
| | [AgentCore Memory](./session-managers/agentcore-memory.md) | Amazon AgentCore | | ||
| | [Valkey](./session-managers/strands-valkey-session-manager.md) | Valkey session manager | | ||
|
|
||
| ## Best Practices and Examples | ||
| ## Integrations | ||
|
|
||
| ### Model Providers | ||
| Platform integrations help you connect Strands agents with external services and user interfaces. | ||
|
|
||
| Model providers enable integration with third-party LLM services by implementing the Strands Agents `Model` interface. Each provider should focus on a single service or platform, exposing configuration parameters through structured config objects that users can customize for their specific needs. | ||
| | Package | Description | | ||
| |---------|-------------| | ||
| | [AG-UI](./integrations/ag-ui.md) | AG-UI integration | | ||
|
|
||
| For detailed implementation guidance including the `ModelConfig` pattern, `stream` method requirements, and `StreamEvent` formatting, see the [Custom Model Provider documentation](../user-guide/concepts/model-providers/custom_model_provider.md). | ||
| --- | ||
|
|
||
| A good example of a community model provider is [strands-clova](https://github.com/aidendef/strands-clova). | ||
| ## Add your package | ||
|
|
||
| ### Tools | ||
|
|
||
| Each tool should have a clear, focused purpose following the single responsibility principle. Use descriptive naming with clear, intuitive names for tools and parameters that make their function obvious to users. Docstrings should include detailed descriptions, parameter explanations, and usage examples to help developers understand how to use your tools effectively. | ||
|
|
||
| The [strands-agents-tools](https://github.com/strands-agents/tools) repository serves as an example community tools package and provides example tools to follow for other tool packages. Good example tools include: | ||
|
|
||
| - [sleep](https://github.com/strands-agents/tools/blob/main/src/strands_tools/sleep.py) - includes explicit error checking with messages that guide the caller on how to correct errors | ||
| - [browser](https://github.com/strands-agents/tools/blob/main/src/strands_tools/browser/__init__.py) - detailing how to support multiple tools that share a common core. | ||
|
|
||
| ## Support & Resources | ||
|
|
||
| Building community packages extends the Strands Agents ecosystem and helps other developers solve complex problems with AI agents. Your contributions make the entire community more capable and productive. | ||
|
|
||
| If you need help or support building community packages, start a discussion in the [Strands Agents SDK repository](https://github.com/strands-agents/sdk-python/discussions). | ||
| Built something useful? We'd love to feature it here. | ||
|
|
||
| See the [Extensions guide](../contribute/contributing/extensions.md) for how to build and publish your package, and the [Get Featured guide](./get-featured.md) for how to get listed in this catalog. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,142 @@ | ||
| # Contributing to core SDK | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The position of Core SDK seems a bit odd here - what are we trying to target by using "Core" - it's sort of distracting
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe Core libraries or something if you're trying to make it distinct from tools? |
||
|
|
||
| The core SDK powers every Strands agent—the agent loop, model integrations, tool execution, and streaming. When you fix a bug or improve performance here, you're helping every developer who uses Strands. | ||
|
|
||
| This guide walks you through contributing to sdk-python and sdk-typescript. We'll cover what types of contributions we accept, how to set up your development environment, and how to submit your changes for review. | ||
|
|
||
| ## What we accept | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could call out the labels; many of the PRs that we reject or ignore are because we didn't really refine or declare that we wanted it. We have labels for features that are open to be contributed |
||
|
|
||
| We welcome contributions that improve the SDK for everyone. Focus on changes that benefit the entire community rather than solving niche use cases. | ||
|
|
||
| - **Bug fixes with tests** that verify the fix and prevent regression | ||
| - **Performance improvements with benchmarks** showing measurable gains | ||
| - **Documentation improvements** including docstrings, code examples, and guides | ||
| - **Features that align with our [roadmap](https://github.com/orgs/strands-agents/projects/8/views/1)** and development tenets | ||
| - **Small, focused changes** that solve a specific problem clearly | ||
|
|
||
| ## What we don't accept | ||
|
|
||
| Some contributions don't fit the core SDK. Understanding this upfront saves you time and helps us maintain focus on what matters most. | ||
|
|
||
| - **Large refactors without prior discussion** — Major architectural changes require a [feature proposal](./feature-proposals.md) | ||
| - **Breaking changes without approval** — We maintain backward compatibility carefully. Breaking changes require a [feature proposal](./feature-proposals.md) | ||
| - **External tools** — [Build your own extension](./extensions.md) instead for full ownership | ||
| - **Changes without tests** — Tests ensure quality and prevent regressions (documentation changes excepted) | ||
| - **Niche features** — Features serving narrow use cases belong in extensions | ||
|
|
||
| If you're unsure whether your contribution fits, [open a discussion](https://github.com/strands-agents/sdk-python/discussions) first. We're happy to help you find the right path. | ||
|
|
||
| ## Set up your development environment | ||
|
|
||
| Let's get your local environment ready for development. This process differs slightly between Python and TypeScript. | ||
|
|
||
| === "Python" | ||
|
|
||
| First, we'll clone the repository and set up the virtual environment. | ||
|
|
||
| ```bash | ||
| git clone https://github.com/strands-agents/sdk-python.git | ||
| cd sdk-python | ||
| ``` | ||
|
|
||
| We use [hatch](https://hatch.pypa.io/) for Python development. Hatch manages virtual environments, dependencies, testing, and formatting. Enter the virtual environment and install pre-commit hooks. | ||
|
|
||
| ```bash | ||
| hatch shell | ||
| pre-commit install -t pre-commit -t commit-msg | ||
| ``` | ||
|
|
||
| The pre-commit hooks automatically run code formatters, linters, tests, and commit message validation before each commit. This ensures code quality and catches issues early. | ||
|
|
||
| Now let's verify everything works by running the tests. | ||
|
|
||
| ```bash | ||
| hatch test # Run unit tests | ||
| hatch test -c # Run with coverage report | ||
| ``` | ||
|
|
||
| You can also run linters and formatters manually. | ||
|
|
||
| ```bash | ||
| hatch fmt --linter # Check for code quality issues | ||
| hatch fmt --formatter # Auto-format code with ruff | ||
| ``` | ||
|
|
||
| To run all quality checks at once (format, lint, and tests across all Python versions), use the prepare script. | ||
|
|
||
| ```bash | ||
| hatch run prepare # Run all checks before committing | ||
| ``` | ||
|
|
||
| **Development tips:** | ||
|
|
||
| - Use `hatch run test-integ` to run integration tests with real model providers | ||
| - Run `hatch test --all` to test across Python 3.10-3.13 | ||
| - Check [CONTRIBUTING.md](https://github.com/strands-agents/sdk-python/blob/main/CONTRIBUTING.md) for detailed development workflow | ||
|
|
||
| === "TypeScript" | ||
|
|
||
| First, we'll clone the repository and install dependencies. | ||
|
|
||
| ```bash | ||
| git clone https://github.com/strands-agents/sdk-typescript.git | ||
| cd sdk-typescript | ||
| npm install | ||
| ``` | ||
|
|
||
| The TypeScript SDK uses npm for dependency management and includes automated quality checks through git hooks. The `prepare` script builds the project and sets up Husky git hooks. | ||
|
|
||
| ```bash | ||
| npm run prepare | ||
| ``` | ||
|
|
||
| Now let's verify everything works by running all quality checks. | ||
|
|
||
| ```bash | ||
| npm run check # Run all checks (lint, format, type-check, tests) | ||
| ``` | ||
|
|
||
| You can also run individual checks. | ||
|
|
||
| ```bash | ||
| npm test # Run unit tests | ||
| npm run test:coverage # Run with coverage (80%+ required) | ||
| npm run lint # Run ESLint | ||
| npm run format # Format code with Prettier | ||
| npm run type-check # TypeScript type checking | ||
| ``` | ||
|
|
||
| **Development tips:** | ||
|
|
||
| - Use `npm run test:integ` to run integration tests | ||
| - Run `npm run test:all` to test in both Node.js and browser environments | ||
| - Check [CONTRIBUTING.md](https://github.com/strands-agents/sdk-typescript/blob/main/CONTRIBUTING.md) for detailed requirements | ||
|
|
||
| ## Find something to work on | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should be higher up and and part of the initial critiera |
||
|
|
||
| Looking for a place to start? Check our issues labeled "ready for contribution"—these are well-defined and ready for community work. | ||
|
|
||
| - [Python SDK issues](https://github.com/strands-agents/sdk-python/issues?q=is%3Aissue+state%3Aopen+label%3A%22ready+for+contribution%22) | ||
| - [TypeScript SDK issues](https://github.com/strands-agents/sdk-typescript/issues?q=is%3Aissue+state%3Aopen+label%3A%22ready+for+contribution%22) | ||
|
|
||
| Before starting work on any issue, check if someone is already assigned or working on it. | ||
|
|
||
| ## Submit your contribution | ||
|
|
||
| Once you've made your changes, here's how to submit them for review. | ||
|
|
||
| 1. **Fork and create a branch** with a descriptive name like `fix/session-memory-leak` or `feat/add-hooks-support` | ||
| 2. **Write tests** for your changes—tests are required for all code changes | ||
| 3. **Run quality checks** before committing to ensure everything passes: | ||
| - Python: `hatch run prepare` | ||
| - TypeScript: `npm run check` | ||
| 4. **Use [conventional commits](https://www.conventionalcommits.org/)** like `fix: resolve memory leak in session manager` or `feat: add streaming support to tools` | ||
| 5. **Submit a pull request** referencing the issue number in the description | ||
| 6. **Respond to feedback** — we'll review within a few days and may request changes | ||
|
|
||
| The pre-commit hooks help catch issues before you push, but you can also run checks manually anytime. | ||
|
|
||
| ## Related guides | ||
|
|
||
| - [Feature proposals](./feature-proposals.md) — For significant features requiring discussion | ||
| - [Team documentation](https://github.com/strands-agents/docs/tree/main/team) — Our tenets, decisions, and API review process | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,117 @@ | ||
| # Contributing to Documentation | ||
|
|
||
| Good documentation helps developers succeed with Strands. We welcome contributions that make our docs clearer, more complete, or more helpful. | ||
|
|
||
| When documentation is missing, unclear, or outdated, developers struggle. Your contributions—whether fixing a typo, clarifying a concept, or adding a new guide—directly improve the experience for thousands of developers. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This paragraph just seems like fluff - can we just remove? |
||
|
|
||
| Documentation lives in the [docs repository](https://github.com/strands-agents/docs). | ||
|
|
||
| ## What we accept | ||
|
|
||
| We're looking for contributions that improve the developer experience. Documentation changes can range from small typo fixes to complete new guides. | ||
|
|
||
| | Type | Description | Examples | | ||
| |------|-------------|----------| | ||
| | Typo fixes | Spelling, grammar, and formatting corrections | Fix misspelled function names, correct punctuation | | ||
| | Clarifications | Rewording confusing sections | Simplify complex explanations, add missing context | | ||
| | New examples | Code samples and tutorials | Working code showing real-world usage | | ||
| | API reference | Improvements to reference documentation | Better parameter descriptions, return value docs | | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is in code; should we have that here? It seems out of place |
||
| | New guides | Complete tutorials or concept pages | Step-by-step workflows, architecture explanations | | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should have a row for community extensions - that's hard coded in the docs right now |
||
|
|
||
| ## Setup | ||
|
|
||
| !!! warning "Migration in progress" | ||
| This section will be rewritten as we migrate to a new CMS. | ||
|
|
||
| Let's get the docs running locally so you can preview your changes as you work. The docs are built with [MkDocs Material](https://squidfunk.github.io/mkdocs-material/). | ||
|
|
||
| ```bash | ||
| # Clone the docs repository | ||
| git clone https://github.com/strands-agents/docs.git | ||
| cd docs | ||
|
|
||
| # Create and activate virtual environment | ||
| python -m venv .venv | ||
| source .venv/bin/activate # On Windows use: .venv\Scripts\activate | ||
|
|
||
| # Install dependencies | ||
| pip install -e . | ||
|
|
||
| # Start the local development server | ||
| mkdocs serve | ||
|
|
||
| # Preview at http://localhost:8000 | ||
| ``` | ||
|
|
||
| The development server automatically reloads when you save changes, so you can see your edits immediately. | ||
|
|
||
| ## Submission process | ||
|
|
||
| The submission process varies based on the size of your change. Small fixes can go straight to PR, while larger changes benefit from discussion first. | ||
|
|
||
| 1. **Fork the docs repository** on GitHub | ||
| 2. **Create a branch** with a descriptive name like `docs/clarify-tools-usage` or `docs/fix-typo-agent-loop` | ||
| 3. **Make your changes** in your favorite editor | ||
| 4. **Preview locally** with `mkdocs serve` to verify formatting and links work correctly | ||
| 5. **Submit a pull request** with a clear description of what you changed and why | ||
|
|
||
| **For small changes** (typos, grammar fixes, minor clarifications), you can skip local preview and go straight to PR. We'll catch any issues in review. | ||
|
|
||
| **For larger changes** (new guides, significant rewrites), we recommend opening a GitHub Discussion first to align on approach and scope. | ||
|
|
||
| ## Style guidelines | ||
|
|
||
| We aim for documentation that teaches, not just describes. A reader finishes understanding the "why" before the "how." This section covers our voice, writing style, and code example conventions. | ||
|
|
||
| ### Voice and tone | ||
|
|
||
| Our documentation uses a collaborative, developer-peer voice. We write as knowledgeable colleagues helping you succeed. | ||
|
|
||
| | Principle | Example | Why | | ||
| |-----------|---------|-----| | ||
| | Use "you" for the reader | "You create an agent by..." not "An agent is created by..." | Direct and personal | | ||
| | Use "we" collaboratively | "Let's install the SDK" not "Install the SDK" | Creates partnership | | ||
| | Active voice, present tense | "The agent returns a response" not "A response will be returned" | Clear and immediate | | ||
| | Explain why before how | Start with the problem, then the solution | Builds understanding | | ||
|
|
||
| ### Writing style | ||
|
|
||
| Keep prose tight and focused. Readers scan documentation looking for answers. | ||
|
|
||
| | Do | Don't | | ||
| |----|-------| | ||
| | Keep sentences under 25 words | Write long, complex sentences with multiple clauses | | ||
| | Use "to create an agent, call..." | Use "in order to create an agent, you should call..." | | ||
| | Include code examples | Describe without showing | | ||
| | Use tables for comparisons | Use long bullet lists for structured data | | ||
| | Add lead-in sentences before lists | Jump directly into bulleted lists | | ||
|
|
||
| ### Code examples | ||
|
|
||
| Code examples are critical—they show developers exactly what to do. Always test your examples before submitting. | ||
|
|
||
| **Requirements:** | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd unbold "Requirements" - the hbolding is a b it overused IMHO |
||
|
|
||
| - **Test all code** — Every example must actually work | ||
| - **Include both languages** — Provide Python and TypeScript when both are supported | ||
| - **Start simple** — Show the minimal example first, then add complexity | ||
| - **Add comments** — Explain non-obvious parts | ||
| - **Use realistic names** — Avoid foo/bar, use descriptive names | ||
|
|
||
| ```python | ||
| # Good: Start simple | ||
| from strands import Agent | ||
| agent = Agent() | ||
| agent("Hello, world!") | ||
|
|
||
| # Then show configuration | ||
| from strands import Agent | ||
| from strands.models import BedrockModel | ||
|
|
||
| agent = Agent( | ||
| model=BedrockModel(model_id="anthropic.claude-3-sonnet"), | ||
| system_prompt="You are a helpful assistant." | ||
| ) | ||
| agent("What's the weather like?") | ||
| ``` | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sidebar still has the old title