Using CodeBot on a Team
We recommend that your team builds shared CodeBot knowledge and tooling into the project. This means that the knowledge, workflow tweaks, etc that each developer adds is committed into source control so the rest of the team benefits.
The project-level agents.md, skills, MCP configuration, and custom agents are team resources. When they are part of the source repo, they are part of how the team works.
Treat them like source files: review them, commit them, and change them in branches or merge requests when appropriate.
You will find them as:
agents.md: a file with that name in your project- Skills, custom agents, and MCP: inside a
.codebotfolder in your project. Make sure your gitignore does not ignore this!
For all the tools described here, you can set up your own personal/local version as well, which works together with anything team-based. This lets you build a common shared set of CodeBot knowledge and tooling but also lets you or any developer have your own custom ways of working with CodeBot. See the Settings where these are configured for more info. By default, all of these are team-based, so you need to explicitly add versions for yourself in that dialog. It's a very powerful mix and we recommend it.
Start With /init
For any non-trivial project, run /init once. This creates or updates a project agents.md file: a Markdown knowledgebase about the project, its structure, and how CodeBot should work in it.
Then, add the new agents.md into source control. Keep it updated as you learn new things that CodeBot needs to know. (CodeBot may sometimes update it itself, too.) That way, when one developer teaches CodeBot something important about the project, other developers can benefit too.
This is an example of a team-based CodeBot workflow: CodeBot learns the project once via one person running /init, and each other team member's CodeBot benefits from that knowledge.
Decide What Belongs Where
Use the project agents.md for team-wide knowledge:
- Architecture notes
- Important folders or units
- Team coding practices
- Gotchas that catch new developers
- How to build, test, or verify common changes
- Areas where CodeBot should be careful
Use personal agents.md for individual preferences.
Add Shared Skills
Skills are useful for team-wide knowledge that is more specialised than the general project overview in agents.md.
Good examples are:
- How to use an in-house component library
- Business rules for your company's domain area
- Project-specific UI rules
- How a particular framework or service is expected to be used
If a skill applies to everyone on the project, keep it with the project and check it in.
Read more on Skills.
Add Custom Agents for In-House Workflows
Custom agents are good for repeated workflows that your team understands but that take several steps to do correctly.
For example, if adding a new report, integration, or plugin always means touching the same kinds of files in the same order, a custom agent can capture that workflow and expose it as a slash command.
Again: write it once, check it in to source control. Every CodeBot across your team can now use it.
Read more on Custom Agents.
Share MCP Configuration Carefully
MCP servers can add tools and capabilities. If those capabilities are useful to the team, project-level MCP configuration lets everyone work the same way.
Be careful here: MCP servers provide external tools and are not run through CodeBot's own sandboxing for file and system access. Treat project MCP configuration as shared development tooling which should be added carefully.
See MCP Settings and Connecting MCP Servers.
Review Through Source Control
CodeBot shows diffs in the chat, and visible form changes can be shown as visual diffs. For team work, though, the review should be your usual one: source control, branches, merge requests, pull requests, or whatever your team already uses. In other words, CodeBot's diffs are for understanding while you work. Git or your normal processes are where team review should still happen.