Contributing
How to contribute to the Monkeys open source projects
Monkeys welcomes contributions across documentation, frontend, backend services, deployment, tools, and workers. Because the ecosystem is split across repositories, the most important first step is choosing the right owning repository.
1. Choose The Owning Repository
Use Repository Map to locate the code owner.
Common examples:
- UI and Studio workflows:
monkeys-studio - Backend workflow APIs, model calls, tool registry, metrics:
monkeys-server - Agent runtime:
monkeys-agent-server - Local deployment references:
monkeys - Public documentation:
monkeys-docs - Tool service behavior: the matching
monkey-tools-*repository
2. Set Up A Local Stack
For backend and frontend changes, use Local Development.
For end-to-end deployment verification, use Deploy From Zero or Docker Compose.
3. Work In A Focused Branch
git checkout -b feat/short-descriptionKeep each pull request focused. A good contribution changes one product behavior, one service boundary, or one documentation topic at a time.
4. Follow Local Project Commands
Each repository owns its own commands. For the most common repositories:
| Repository | Useful checks |
|---|---|
monkeys-server | yarn build, yarn lint, yarn test, yarn test:e2e when relevant |
monkeys-studio | yarn build, yarn lint, yarn test |
monkeys-docs | yarn format:check, yarn build |
When a repository has AGENTS.md, read it before making changes. It may include local architecture rules, testing expectations, or generated-file constraints.
5. Database Changes
For monkeys-server, table changes require migrations:
yarn migration:create
yarn migration:runRename the generated migration file and class to describe the change. New table names should use config.server.appId as the prefix.
6. Documentation Changes
Public documentation should use GitHub repository URLs under https://github.com/infmonkeys/....
Keep docs focused on product behavior, deployment, development, and contribution. Avoid adding one-off walkthrough articles or private operational notes to public docs.
7. Pull Request Checklist
Before opening a pull request:
- The owning repository is correct.
- Commands relevant to the changed repository pass.
- New behavior has a focused test or a clear manual verification note.
- Config examples do not contain secrets.
- Public links use the
infmonkeysGitHub organization. - Documentation and code agree on service names, ports, and repository boundaries.