Contributing to Clawith ๐Ÿฆž

April 3, 2026 ยท View on GitHub

Thanks for your interest in contributing! Whether it's a bug fix, new feature, translation, or documentation improvement โ€” every contribution matters.

Quick Start

  1. Fork this repo and clone your fork
  2. Set up the dev environment:
    bash setup.sh    # Backend + frontend + database
    bash restart.sh  # Start services โ†’ http://localhost:3008
    
  3. Create a branch: git checkout -b my-feature
  4. Make your changes
  5. Push and open a Pull Request

What Can I Contribute?

AreaExamples
๐Ÿ› Bug fixesUI glitches, API errors, edge cases
โœจ FeaturesNew agent skills, tools, UI improvements
๐Ÿ”ง MCP IntegrationsNew MCP server connectors
๐ŸŒ TranslationsNew languages or improving existing ones
๐Ÿ“– DocumentationREADME, guides, code comments
๐Ÿงช TestsUnit tests, integration tests

New to the project? Look for issues labeled good first issue.

Bug Reports

When reporting a bug, please include:

  • Steps to reproduce
  • Expected vs actual behavior
  • Clawith version and deployment method (Docker / Source)
  • Logs or screenshots if available

Priority guide:

TypePriority
Core functions broken (login, agents, security)๐Ÿ”ด Critical
Non-critical bugs, performance issues๐ŸŸก Medium
Typos, minor UI issues๐ŸŸข Low

Feature Requests

Please describe:

  • The problem you're trying to solve
  • Your proposed solution (if any)
  • Why this would be useful

Pull Request Process

  1. Link an issue โ€” Create one first if it doesn't exist
  2. Keep it focused โ€” One PR per feature/fix
  3. Test your changes โ€” Make sure nothing is broken
  4. Follow code style:
    • Backend: Python โ€” formatted with ruff
    • Frontend: TypeScript โ€” standard React conventions
  5. Use Fixes #<issue_number> in the PR description

Working on Multiple Features

It is common to develop several improvements in one sitting before submitting. Rather than sending one giant PR, please split your work into smaller, focused PRs โ€” this makes review faster and merges cleaner.

Preferred: one branch per feature from the start

# Start each new feature from a fresh branch off main
git checkout main && git pull
git checkout -b feat/i18n-emoji-cleanup

# ... develop, commit ...

git checkout main
git checkout -b feat/admin-email-templates

# ... develop, commit ...

Each branch becomes one PR. Small, clean, easy to review.

Already mixed everything into one branch? Split it with git add -p

git add -p (patch mode) lets you selectively stage individual change hunks from a file โ€” perfect for creating several commits from one messy branch.

Step-by-step example:

# Assume your branch is called my-big-branch and has 3 logical changes mixed in.
# Goal: create 3 separate PRs from it.

# --- PR 1: emoji cleanup ---
git checkout -b feat/i18n-emoji-cleanup main

# Interactively stage only the emoji-related hunks from en.json and zh.json:
git add -p frontend/src/i18n/en.json   # answer y/n for each hunk
git add -p frontend/src/i18n/zh.json
git commit -m "fix: remove emoji from i18n strings"
git push -u origin feat/i18n-emoji-cleanup
# โ†’ open PR

# --- PR 2: hardcoded strings โ†’ t() ---
git checkout -b feat/i18n-component-strings main

git add -p frontend/src/pages/AgentDetail.tsx   # stage only t() hunk
git add -p frontend/src/components/ChannelConfig.tsx
git commit -m "feat: replace hardcoded UI strings with i18n t() calls"
git push -u origin feat/i18n-component-strings
# โ†’ open PR

# --- PR 3: admin improvements ---
git checkout -b feat/admin-improvements main
git checkout my-big-branch -- frontend/src/pages/AdminCompanies.tsx  # cherry-pick whole file if clean
git commit -m "feat: improve admin company settings"
git push -u origin feat/admin-improvements
# โ†’ open PR

Key commands:

CommandWhat it does
git add -p <file>Stage hunks interactively (y = yes, n = no, s = split hunk smaller)
git checkout <branch> -- <file>Copy a whole file from another branch
git cherry-pick <commit>Apply a single commit to the current branch
git diff main...HEAD -- <file>Preview what changed in a specific file vs main

Tips

  • Commit early, commit often on your dev branch โ€” individual commits are much easier to cherry-pick later than one large commit.
  • Use descriptive commit messages (e.g. fix: remove emoji from zh.json, not update stuff).
  • If two features touch the same file heavily, submit PR 1 first, wait for it to merge, then rebase PR 2 on main before opening it.

Project Structure

backend/
โ”œโ”€โ”€ app/
โ”‚   โ”œโ”€โ”€ api/          # FastAPI route handlers
โ”‚   โ”œโ”€โ”€ models/       # SQLAlchemy models
โ”‚   โ”œโ”€โ”€ services/     # Business logic
โ”‚   โ””โ”€โ”€ core/         # Auth, events, middleware
frontend/
โ”œโ”€โ”€ src/
โ”‚   โ”œโ”€โ”€ pages/        # Page components
โ”‚   โ”œโ”€โ”€ components/   # Reusable UI components
โ”‚   โ”œโ”€โ”€ stores/       # Zustand state management
โ”‚   โ””โ”€โ”€ i18n/         # Translations

Language Policy

To ensure all contributors can participate effectively, please use English for issues, PRs, and code comments.

ไธบไบ†็กฎไฟๆ‰€ๆœ‰่ดก็Œฎ่€…้ƒฝ่ƒฝๆœ‰ๆ•ˆๅ‚ไธŽ๏ผŒ่ฏทไฝฟ็”จ่‹ฑ่ฏญๆไบค Issueใ€PR ๅ’Œไปฃ็ ๆณจ้‡Šใ€‚

ใ™ในใฆใฎใ‚ณใƒณใƒˆใƒชใƒ“ใƒฅใƒผใ‚ฟใƒผใŒๅŠนๆžœ็š„ใซๅ‚ๅŠ ใงใใ‚‹ใ‚ˆใ†ใ€Issueใ€PRใ€ใ‚ณใƒผใƒ‰ใ‚ณใƒกใƒณใƒˆใฏ่‹ฑ่ชžใงใŠ้ก˜ใ„ใ—ใพใ™ใ€‚

๋ชจ๋“  ๊ธฐ์—ฌ์ž๊ฐ€ ํšจ๊ณผ์ ์œผ๋กœ ์ฐธ์—ฌํ•  ์ˆ˜ ์žˆ๋„๋ก, Issue, PR, ์ฝ”๋“œ ์ฝ”๋ฉ˜ํŠธ๋Š” ์˜์–ด๋กœ ์ž‘์„ฑํ•ด ์ฃผ์„ธ์š”.

Para garantizar que todos los contribuidores puedan participar de manera efectiva, utilice inglรฉs para issues, PRs y comentarios de cรณdigo.

ู„ุถู…ุงู† ู…ุดุงุฑูƒุฉ ุฌู…ูŠุน ุงู„ู…ุณุงู‡ู…ูŠู† ุจูุนุงู„ูŠุฉุŒ ูŠุฑุฌู‰ ุงุณุชุฎุฏุงู… ุงู„ู„ุบุฉ ุงู„ุฅู†ุฌู„ูŠุฒูŠุฉ ููŠ ุงู„ู€ Issues ูˆุทู„ุจุงุช ุงู„ุณุญุจ ูˆุชุนู„ูŠู‚ุงุช ุงู„ูƒูˆุฏ.

Windows Development

Clawith is primarily developed on Linux/macOS, but can run on Windows with a few adjustments.

Prerequisites

  • Python 3.11+ โ€” Install from python.org (check "Add to PATH")
  • Node.js 18+ โ€” Install from nodejs.org
  • Docker Desktop โ€” For PostgreSQL and Redis (recommended over native installs)

Database & Redis via Docker

docker run -d --name clawith-postgres -p 5432:5432 -e POSTGRES_PASSWORD=yourpass -e POSTGRES_DB=clawith postgres:15
docker run -d --name clawith-redis -p 6379:6379 redis:7

Backend Setup

cd backend
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt

# Create .env (copy from .env.example and adjust DATABASE_URL / REDIS_URL)
# Run database migrations
alembic upgrade head

# Start the server
uvicorn app.main:app --host 0.0.0.0 --port 8000

Frontend Setup

cd frontend
npm install
npm run dev

Common Windows Issues

IssueSolution
UnicodeEncodeError / GBK encodingSet PYTHONUTF8=1 in environment variables, or run chcp 65001 before starting
System proxy intercepting LLM API callsSet NO_PROXY=* or unset HTTP_PROXY / HTTPS_PROXY in your terminal
uvicorn --reload crashes with watchfilesRemove --reload flag, or install watchfiles: pip install watchfiles
File path errors with backslashesUse pathlib.Path โ€” the codebase already does this in most places

Note: The recommended deployment method is Docker (docker compose up -d), which works identically on Windows, macOS, and Linux. The instructions above are for local development without Docker.

Getting Help

Stuck? Open a Discussion or ask in the related issue. We're happy to help! ๐Ÿ™Œ