A connection makes repositories available. A project is what Coroid actually works in: one project maps to one repository, and carries that repository's build commands, test commands, context and settings.
Create one from Projects → New.
What happens on creation
Coroid clones the repository and does a first pass over it. That pass works out:
- which languages and frameworks are present
- how the project is built
- how its tests are run
- whether it can be containerised
This analysis is what later lets an agent compile your code and run your suite. It is worth two minutes of your attention now, because everything downstream depends on it being right.
Check what it detected
Open the project's settings and confirm the build and test commands. Detection is good on conventional layouts and less good on:
- monorepos, where the commands live in a subdirectory
- projects needing a setup step (code generation, migrations) before tests run
- suites that need services — a database, a queue — to be up first
If any of those apply, correct the commands by hand. An agent that cannot run your tests cannot verify its own work, and you will see that surface later as tasks failing in verification for reasons that have nothing to do with the change.
Language support
Coroid's depth varies by language. The compatibility matrix lists each supported language against build, test, container and language-server support, with an honest status per combination — "partial" and "setup required" mean what they say.
One repository or several?
One project per repository. If your system spans several repositories, create a project for each; Coroid can then coordinate work that crosses them.
Resist the urge to point two projects at the same repository to represent different workstreams — use plans, sprints or lanes for that instead, so the two streams share one view of the codebase.
Next
Run your first task — describe some work and watch it through.