SkillsAdd

conductor.build

conductor

Configure, operate, and troubleshoot Conductor — workspaces, repository settings.toml files, scripts, files to copy, managed settings, agent controls, and review workflows. Use when helping someone set up or operate Conductor.

First seen May 7, 2026

Installation

$ npx skills add https://conductor.build
View on skills.sh ↗ Website ↗

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

agent-browser Shared topics
vercel-labs/agent-browser

Browser automation CLI for AI agents. Use when the user needs to interact with websites, includ…

810.4K installs
vercel-react-best-practices Shared topics
vercel-labs/agent-skills 697.8K installs
web-design-guidelines Shared topics
vercel-labs/agent-skills

Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "chec…

617.3K installs
microsoft-foundry Shared topics
microsoft/azure-skills

Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and …

576.5K installs
azure-hosted-copilot-sdk Shared topics
microsoft/azure-skills 440.4K installs
azure-enterprise-infra-planner Shared topics
microsoft/azure-skills

Architect and provision enterprise Azure infrastructure from workload descriptions. For cloud a…

402.8K installs
More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Declared
Cursor Declared
Codex Declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Skill metadata

Parsed from SKILL.md frontmatter.

LicenseProprietary
CompatibilityConductor runs coding agents in isolated workspaces, either locally in git worktrees on the user's Mac or in Linux cloud sandboxes.
Declared agents claude-code cursor codex

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 9,190 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 137 installs

SKILL.md

Conductor

Conductor is an app for running multiple coding agents in parallel, each in an isolated workspace. It supports Claude Code, Codex, Cursor Agent, and OpenCode. The desktop app is Mac-only; cloud workspaces run on Linux and can be driven from the Mac app, the iOS app, or the public API.

This file covers the facts that are easy to get wrong. For anything else, fetch the docs page linked in the relevant section.

Know your environment

Check CONDUCTORISLOCAL before giving environment-specific guidance: 1 = you are running locally on the user's Mac; 0 = you are in a Conductor cloud sandbox (Linux).

  • Local: your session runs in a git worktree on the user's Mac, with the user's local permissions. Each repository has a main root directory and one worktree per workspace. New workspaces are created from the repository's configured base branch; Conductor fetches from origin first, so a workspace starts from the latest remote commit even when the local checkout is behind (the fetch does not move the branch checked out in the root directory).
  • Cloud: your session runs in a Linux sandbox with a single checkout of the repository. You have no access to the user's machine or its filesystem — unless the Conductor RunLocalCommand tool is available, which runs a one-shot shell command on the user's Mac. Cloud workspaces can be created from the Mac app, the iOS app, or the API, so do not assume a Mac client.

Docs:

Settings files

  1. Machine-local, one repository: <repo>/.conductor/settings.local.toml.
  2. Shared with the team: <repo>/.conductor/settings.toml — the Mac app reads it from the default branch on the remote, so merge it before it takes effect locally; cloud setup reads it from the branch the workspace is created from.
  3. This user, all repositories: ~/.conductor/settings.toml.
  4. Organization-controlled: ~/.conductor/settings.managed.toml.

Precedence: managed > repository local > repository shared > user > built-in defaults. Any TOML file outranks any legacy JSON file, regardless of layer; Conductor writes new settings as TOML.

Schemas:

  • User settings: https://conductor.build/schemas/settings.schema.json
  • Repository settings: https://conductor.build/schemas/settings.repo.schema.json
  • Managed settings: https://conductor.build/schemas/settings.toml.json

Docs:

Repository settings and scripts

A typical <repo>/.conductor/settings.toml:

"$schema" = "https://conductor.build/schemas/settings.repo.schema.json"

[scripts]
setup = "pnpm install"
run_mode = "concurrent"

[scripts.run.dev]
available_in = [ "local" ]
command = "pnpm dev --port $CONDUCTOR_PORT"
default = true
icon = "play"

[scripts.run.test]
command = "pnpm test:watch"
icon = "test-tube"

The schema and settings docs list every key. Facts worth knowing:

  • Setup, run, and archive scripts run from the workspace directory in non-interactive shells: zsh on the user's Mac (with the login shell environment captured), bash in cloud workspaces. Put required toolchain setup in the scripts themselves rather than relying on interactive shell startup.
  • Local workspaces get ten ports, CONDUCTORPORT through CONDUCTORPORT+9. CONDUCTORPORT is unset in cloud workspaces, so mark run scripts that depend on it availablein = [ "local" ].
  • Use run_mode = "concurrent" only when multiple workspaces can run at the same time (separate ports, no shared database or Docker stack); otherwise nonconcurrent.
  • scripts.run.<id>.available_in takes local, cloud, or both; omit it to show the script everywhere.
  • icon values are lowercase-kebab Lucide names; invalid names fall back to play.
  • Legacy single-string scripts.run is still read and is migrated to [scripts.run.<id>] when Conductor rewrites the file.
  • When one run script starts multiple processes, keep them in the same process group (e.g. concurrently) instead of backgrounding with &.
  • Use Spotlight testing when a project cannot run from a worktree and must execute from the repository root.
  • Settings that are not repository-configurable include model defaults, reasoning defaults, tool approvals, and the default workspace location — those live in user settings.

Environment variables available to scripts and agents:

  • CONDUCTORWORKSPACENAME: Workspace name.
  • CONDUCTORWORKSPACEID: Workspace ID in agent and terminal processes. The conductor CLI uses it when a workspace argument is omitted.
  • CONDUCTORWORKSPACEPATH: Workspace path.
  • CONDUCTORROOTPATH: Repository root directory. In cloud workspaces this equals the workspace path.
  • CONDUCTORDEFAULTBRANCH: Default branch name. Local workspaces only.
  • CONDUCTOR_PORT: First of the ten allocated ports. Local workspaces only.
  • CONDUCTORISLOCAL: 1 on the user's Mac, 0 in a cloud workspace. Branch on this in scripts.setup for local-only steps.

Docs:

Files to copy

For static gitignored files (.env files, local config, certificates) that every new workspace needs, use Files to copy rather than a setup script. Resolution order:

  1. .worktreeinclude at the repository root.
  2. fileincludeglobs in repository settings.
  3. Default .env* pattern.

Use scripts.setup when the workspace needs commands run: dependency installs, generated files, symlinks.

Docs:

Managed settings

Organization-controlled settings live at ~/.conductor/settings.managed.toml (legacy settings.managed.json is still read). Managed values override user and repository settings and disable the matching controls in Settings. Managed settings are provisional.

Docs:

Legacy conductor.json

The Mac client ignores repo-level conductor.json once <repo>/.conductor/settings.toml exists, but cloud setup still falls back to a conductor.json setup script when no settings TOML defines one — delete conductor.json once migrated. Migration map:

  • scripts.setup -> scripts.setup
  • scripts.run -> scripts.run.<id>.command
  • scripts.archive -> scripts.archive
  • runScriptMode -> scripts.run_mode
  • enterpriseDataPrivacy -> enterprisedataprivacy

Docs:

Agent controls

Plan mode, fast mode, reasoning controls, Codex personality, checkpoints, MCP, slash commands, todos, and instruction files are covered in the docs:

Review and merge

When leaving review feedback from inside Conductor, use the Conductor DiffComment tool when it is available — comments appear in the app's Checks panel. Do not post review feedback to GitHub unless the user explicitly asks for GitHub comments.

Docs:

Troubleshooting

Non-obvious causes to check first:

  • Setup or run scripts that depend on interactive shell startup behavior (they run in non-interactive shells).
  • Missing files that are gitignored and should be copied via Files to copy or .worktreeinclude.
  • A shared resource (fixed port, single database, Docker stack) that needs run_mode = "nonconcurrent" or Spotlight testing.
  • Managed settings in ~/.conductor/settings.managed.toml overriding what the user set.
  • A legacy conductor.json being ignored by the Mac client because .conductor/settings.toml exists.

Docs: