Turbo Editors — configuration samples

Ready-made project configurations for the Turbo editors: one directory per kind of project, each holding the editor's own directory — .turbo-go, .turbo-rust — with its settings, snippets, tools and, in the variants that ship them, its coding agents and their skills.

You do not clone this repository to use it. Every Turbo editor can fetch a directory from it straight into your project.

Load a configuration into a project

From the directory of your project, give the editor the URL of the sample as the browser shows it:

cd my-go-project
turbo-go -load-config https://rickub.com/turbo-editors/configs/tree/main/golang-init

The editor looks for the .turbo-go directory inside golang-init, copies it into the current directory, prints what arrived, and exits:

Copied /path/to/my-go-project/.turbo-go from https://git.rickub.com/turbo-editors/configs.git (main):
  settings.toml
  snippets.toml
  tools.toml

Then start the editor as usual — turbo-go, turbo-go main.go — and the settings, snippets and tools are in force.

Each editor looks for its own directory: turbo-rust copies the .turbo-rust of the sample you point it at, turbo-python a .turbo-python, and so on. Pointing turbo-rust at a Go sample ends in an error saying there is no .turbo-rust there.

cd my-rust-project
turbo-rust -load-config https://rickub.com/turbo-editors/configs/tree/main/rustlang-init-with-agents

What to know

• git must be installed. The fetch is a shallow git clone; no token and no account are needed for this public repository.
• A project that already has the directory is left alone. The editor refuses rather than overwrite what the project decided. Move the existing .turbo-<editor> away first if you mean to replace it.
• The URL may be any of these: the sample's directory (…/tree/main/golang-init), the editor's directory inside it (…/tree/main/golang-init/.turbo-go), or a file in it. A branch or tag other than main works the same way, from the URL the browser shows for it.
• The same works from other forges. GitHub, GitLab and Codeberg URLs are understood too, so a team can keep its own samples wherever its code lives.
• Nothing else is copied: the sample's README.md and anything beside the editor's directory stay here.

The samples

Directory	Editor	Holds
golang-init	turbo-go	settings.toml (theme turbo-dark, autosave on after 1 s), snippets.toml, tools.toml (format, lint, build, test, run, plus a prompting Grep and go mod init)
golang-init-with-agents	turbo-go	The same, plus acp.toml naming two coding agents and the two agent settings files they read
golang-with-skills	turbo-go	The same as -with-agents, with theme intellij-light, the agents' thinking shown, and a skills/ directory the agents load
rustlang-init	turbo-rust	settings.toml, snippets.toml, tools.toml for a Cargo project
rustlang-init-with-agents	turbo-rust	The same, plus the two agents

The agents in the samples that ship them

acp.toml declares two agents, both run as mm -acp — a local agent speaking the Agent Client Protocol — each with its own settings file beside it (agent.mm-dmr-gemma.yaml, agent.mm-dmr-mellum.yaml), passed through the AGENT_CONFIG environment variable. Those files point at a Docker Model Runner serving models on http://localhost:12434, with host.docker.internal as the fallback. To use them you need mm on your PATH and Docker Model Runner running with the named models; otherwise the Agent menu lists the agents and opening one reports that it could not start.

Edit the two YAML files after loading — the model, the URL, which tools the agent may use — exactly as you would any project file. They are yours once copied.

The skills in golang-with-skills

A skill is a Markdown file telling the agent how to do one kind of job: front matter with a name, a description and keywords, then the instructions under it. The agent reads the front matter of every skill it finds and opens the file itself only when a question matches — so a skill costs nothing until it is needed.

Both agent YAML files in this sample set skillsDir: skills, a path relative to the agent settings file, which puts the skills in .turbo-go/skills/ — copied with the rest of the directory. What is in there:

Skill	For
lsp-navigation	Using the lsp tool instead of grep: definition, references, hover, file outline, diagnostics, safe rename
bg-jobs	Starting a server or a watcher without blocking the answer — redirect both streams, keep the pid, poll for ready, stop it afterwards
greetings, vulcan-salute, what-time-is-it	Three one-command demo skills, there to show that a skill is picked up and run

lsp-navigation and bg-jobs are worth keeping in a real project; the last three are for seeing the mechanism work — ask an agent the time, or to salute someone, and watch it run the command the skill names rather than answer from memory. Delete them once you have.

Add your own by creating a directory under skills/ with a SKILL.md in it. The description and keywords are what the agent matches a question against, so write them for the question, not for the solution.

Add a sample

1. Create a directory named for the kind of project: <language>-<flavour>.
2. Put the editor's directory inside it — .turbo-<editor>/ with at least settings.toml; add snippets.toml, tools.toml, and acp.toml with its agent files if the sample ships agents, and a skills/ directory if those agents have skills. The starter files an editor creates from its Options menu are a good beginning.
3. Add a README.md saying what the sample is for and what it assumes is installed.
4. Do not commit anything an agent writes while you test the sample: .mm/ is ignored for that reason.

The editors only read .turbo-<editor>/, so a sample may hold the same configuration for several editors side by side — .turbo-go and .turbo-rust in one directory — and each editor takes its own.