Configuration

Developer reads its config from a developer.yaml file at the project root. Copy example.developer.yaml to developer.yaml and customize it — developer.yaml is gitignored. This file defines which repos it manages, how to set them up locally, and what quality tools to run.

Format

repos:
  assistant:
    github:
      owner: gregology
      repo: assistant
    testing_philosophy: >-
      Test rigor is proportional to irreversibility.
      Dispatch, provenance, and non-undoable actions need thorough tests.
    setup:
      - uv sync --all-extras
      - mkdir -p .claude
      - test -f .claude/settings.local.json || echo '{}' > .claude/settings.local.json
    quality_tools:
      - name: mypy
        cmd: [uv, run, mypy, app/, --ignore-missing-imports]
      - name: ruff
        cmd: [uv, run, ruff, check, app/, tests/]

Fields

repos (required)

Top-level key. Each entry underneath is a repo, keyed by whatever name you want to use on the command line.

github (required)

GitHub coordinates:

github:
  owner: gregology
  repo: assistant

Both owner and repo are required. Developer uses these to construct API URLs, clone URLs, and the bot's commit identity.

setup (optional)

List of shell commands to run after cloning or pulling. These run in the repo's root directory.

setup:
  - uv sync
  - npm install
  - bundle install

Commands run with shell=True, so pipes and redirects work. If a setup command fails, Developer logs a warning and continues. The validate command is stricter -- it tracks per-step pass/fail.

quality_tools (optional)

List of tools that check code quality. Each needs a name and a cmd (as a list of strings):

quality_tools:
  - name: ruff
    cmd: [uv, run, ruff, check, src/, tests/]
  - name: mypy
    cmd: [uv, run, mypy, --ignore-missing-imports]

Quality tools run during the resolve and address pipelines (after implementation, before opening a PR). They also run during audit refactor as signal for the agent. If a tool fails, the agent gets up to three attempts to fix the issues.

provider (optional)

Default agent provider for all pipeline stages. Defaults to claude. Available providers: claude, pi.

provider: pi

The CLI --provider flag on any command overrides this default. See CLI reference for details.

providers (optional)

Per-stage provider overrides. Maps stage names to provider names, letting you use different providers for different pipeline stages. Stages not listed here fall back to the provider default.

provider: claude
providers:
  triage: pi
  implementation: pi

In this example, triage and implementation stages use pi while all other stages use claude.

Stage names correspond to the pipeline stages for each command (e.g., triage, decompose, implementation, evaluation, docs_review, craft_pr for resolve; analyze, review_findings, draft for review; analyze_feedback, implement, craft_update for address).

testing_philosophy (optional)

Free-text description of the repo's testing approach. This gets injected into audit prompts so the agent understands what kind of test coverage the project expects.

testing_philosophy: >-
  Real user scenarios, no mocks, no private function tests.

Validation

Developer validates config on every run. If something is wrong, you get a specific error:

ConfigError: repos.assistant.github: missing required key 'owner'

You can also validate that a repo's full config works from scratch:

developer validate assistant
developer validate --all

This clones into a temp directory, runs every setup command, runs every quality tool, and reports pass/fail for each step. It proves the config actually works, not just that it parses.

Adding a repo

Add a block under repos in your developer.yaml:

repos:
  my-new-repo:
    github:
      owner: myorg
      repo: my-new-repo
    setup:
      - npm install
    quality_tools:
      - name: eslint
        cmd: [npx, eslint, src/]

Developer clones it on first run. No other setup needed.