Skip to content

Latest commit

 

History

History
113 lines (76 loc) · 5.39 KB

CONTRIBUTING.md

File metadata and controls

113 lines (76 loc) · 5.39 KB

Contributing to tambo

Thank you for contributing! This guide outlines our workflow and the quality bar for changes. Please read it end-to-end before opening a PR.

Code of Conduct

By participating, you agree to uphold a respectful, inclusive environment. Be kind, constructive, and collaborative.

Workflow overview

  1. Open or pick up an issue. If your change touches the API, open a companion issue/PR in the tambo-cloud repository and cross-link. See its CONTRIBUTING.md.
  2. Create a feature branch from main.
  3. Implement your change with tests and docs.
  4. Open a PR with a semantic versioning title and the checklist below.
  5. Get at least one approval and a green CI run.

PR titles and semantic versioning (required)

We infer release impact from PR titles using Conventional Commits semantics. Use one of:

  • feat(scope): add something → Minor version bump
  • fix(scope): fix something → Patch version bump
  • perf(scope): ..., refactor(scope): ..., docs(scope): ..., chore(scope): ... → Typically patch or no release
  • feat(scope)!: breaking change summary or include a BREAKING CHANGE: footer → Major version bump

Examples:

  • feat(button): add destructive variant
  • fix(table): restore keyboard navigation
  • feat(api)!: remove deprecated v1 endpoints

Scopes are usually package or area names (e.g., button, cli, docs, sdk). Keep titles clear and imperative.

Cross-repo and API changes

  • If your change depends on backend work, open/link a PR in the tambo-cloud repository and reference it in your PR description.
  • Keep API discussions and schema reviews in the tambo-cloud PR. Frontend PRs should not block on SDK updates; see SDK policy below.

TypeScript SDK policy (Stainless-generated)

  • The TypeScript SDK is auto-generated by Stainless from the API schema.
  • Do not modify the SDK by hand. Instead, land the API change in tambo-cloud; when deployed, the SDK will be regenerated by automation.
  • If you need new client behavior, propose it via API changes or helper utilities that wrap the generated client in this repo (not edits to generated files).

Visual changes require a short video demo

Any PR that changes visuals (new component, component behavior/style, or UI in tambo-cloud) must include a brief demo video (≤ 2 minutes). Loom links are fine. Show:

  • Where to find the feature
  • Before vs after (if applicable)
  • Key interactions and edge cases

Documentation is mandatory

All changes must update our documentation site. Include:

  • Updated reference pages (props, usage, examples)
  • New guides or tutorial steps if introducing concepts
  • Migration notes if behavior changes

Link the docs PR or commit in your PR description.

Component library changes must update showcase and CLI

  • Add or update examples in the component showcase so reviewers can validate visually
  • Update the CLI so new components can be scaffolded/added by the CLI
  • Add a minimal usage example to the docs and CLI help output where applicable

AI-generated code policy

  • Any AI-generated code must be reviewed by a human and brought up to our readability, testing, and documentation standards.
  • Follow our internal AI rules/policy document (link internally). Do not include secrets or customer data in prompts.

Quality bar

  • TypeScript, ESLint, and Prettier must pass: pnpm -w lint and pnpm -w typecheck
  • Tests must pass locally and in CI: pnpm -w test
  • Add tests for new logic and meaningful changes
  • Keep functions small, well-named, and guard edge cases early

PR checklist (include in description)

  • Semantic PR title using Conventional Commits (feat, fix, ! for breaking)
  • Linked issue(s)
  • If API-related: linked tambo-cloud PR and notes (PRs that depend on cloud must link it so we can prioritize that PR)
  • If SDK needed: confirm it will be regenerated by Stainless (no manual SDK edits)
  • JSDoc updated in code where relevant
  • Docs site updated (pages/examples/CLI help), or a separate doc PR is linked
  • Visual change demo video attached (≤ 2 min)
  • Showcase updated for component changes
  • CLI updated to support new components or options
  • Tests added/updated and all CI checks green

Branching, commits, and reviews

  • Branch from main, rebase as needed to keep history clean
  • Use small, focused commits with clear messages (Conventional Commits encouraged, but PR title governs versioning)
  • At least one reviewer approval required; request experts for API or design-heavy changes

Releases

  • We follow Semantic Versioning (semver). Release type is derived from PR titles and/or maintainer input
  • Changelogs are generated by CI (or maintainers) based on merged PRs
  • Maintainers may squash and edit titles to reflect the correct semver impact

Links

Thanks for helping improve tambo!