Konfigurationsdatei

Die kanonische Datei ist .agentflow/config.yaml, angelegt durch agentflow init aus config.yaml.example. Relative Pfade löst AgentFlow von der Repository-Wurzel aus. Das generierte JSON-Schema zur maschinellen Validierung liegt auf der Docs-Site unter /schemas/config.schema.json.

Die folgenden Abschnitte folgen dem Aufbau der Datei: Jeder Block steuert einen Teilbereich — Intent, Standardwerte für work, Quellen, Persistenz, Agents, Validierung, Modelle, Kosten, Routing, UI, MCP und Repository-Richtlinien.

project

Projektname und Standardbranch für worktree-orientierte Abläufe.

project:
  name: my-project
  default_branch: main

intent

Konfiguration für die Auflösung natürlicher Sprache bei work und continue (application/internal/intent): Resolver an oder aus, Modus, Verhalten bei niedriger Konfidenz und optionaler Ollama-Fallback.

intent:
  enabled: true
  default_mode: guided   # guided | auto
  resolver:
    use_ollama_fallback: true
    min_confidence: 0.75
    ask_when_below_confidence: true

work

Repo-weite Defaults für die Orchestrierung: welche Agents welche Rollen haben, wo die Pipeline stoppt, Schalter für Verifikation und Review, Task-Limits und ob eine Planbestätigung verlangt wird.

work:
  default_agent: cursor
  default_reviewer: codex
  default_enricher: ollama
  stop_after: report
  auto_verify: true
  auto_review: false
  max_tasks_per_run: 1
  require_plan_confirmation: true

sources

Lokale Quellen durchsuchen feste Pfade nach Specs und aktivem Handoff; Notion ist optional und importiert Snapshots in den Baum.

sources:
  local:
    enabled: true
    paths:
      - .agentflow/specs
      - .kiro/specs
      - docs/ai/active
  notion:
    enabled: false
    token_env: NOTION_TOKEN
    specs_database_id: ""
    import_path: .agentflow/specs

specs, state, worktrees

Pfade für Kiro-artige Specs, SQLite-State und Worktree-Layout. cleanup_policy steuert das Aufräumen unter worktrees.base_path.

specs:
  kiro_path: .kiro/specs
  active_spec_path: docs/ai/active/current-spec.md
  handoff_path: docs/ai/active/handoff.md

state:
  backend: sqlite
  path: .agentflow/state.sqlite

worktrees:
  base_path: .agentflow/worktrees
  branch_prefix: agentflow
  cleanup_policy: keep_failed

agents

Logische Agent-IDs auf Unterprozess-Kommandos abbilden: Agenten-Konfiguration.

validation

validation.commands listet Prüfungen (Tests, Linter, eigene Skripte). Bei Go-Repos liefert der Bootstrap oft Defaults, wenn go.mod vorhanden ist.

validation:
  commands:
    - name: tests
      command: go test ./...
      required: true

models

Logische Profile für Routing und Kosten (specv3). Schlüssel sind frei wählbare IDs; jeder Eintrag verbindet Provider, Cost-Klasse, Modellnamen und erlaubte Nutzungsklassen.

models:
  ollama_local_qwen:
    provider: ollama
    class: local
    model: qwen2.5-coder:14b
    input_cost_per_1m_tokens: 0
    output_cost_per_1m_tokens: 0
    usage: [summarize, classify, pre_review, context_selection]

budgets

Obergrenzen pro Run, Task und Tag: Budgets.

pricing

Grenzkosten für Cloud und lokal kommen aus Ihrem YAML — keine fest eingebauten Cloud-Preise im Code. Ein aktuelles updated_at zeigt, wann Zahlen zuletzt mit einer Preisliste abgeglichen wurden.

pricing:
  currency: EUR
  models:
    gemini-3-flash-preview:
      input_per_1m_tokens: 0.00
      output_per_1m_tokens: 0.00
      source: manual
      updated_at: "2026-05-17"

token_estimation

Token-Zahlen fürs Budget nutzen Heuristiken zu Zeichen pro Token (application/internal/cost/token_counter.go). Feinanpassung rückt Schätzungen näher an Ihre Mischung aus Code und Prosa.

token_estimation:
  default_chars_per_token: 4.0
  code_chars_per_token: 3.2
  markdown_chars_per_token: 4.2
  json_chars_per_token: 3.6

routing

Schrittklassen zu lokalen oder Cloud-Agents: Routing.

ui

Terminal-Verhalten (application/internal/tui): Darstellungsmodus, Live-Logs, Fortschrittsbalken, kompakte Ausgabe.

ui:
  mode: auto      # auto | rich | plain | json
  live_logs: true
  progress_bars: true
  compact: false

mcp

Wenn mcp.enabled true ist, kann AgentFlow einen lokalen stdio-MCP-Server mit Tool-Timeouts, Ausgabelimits, Investigation-Caps und Pfaden betreiben, die Investigation nicht lesen darf.

mcp:
  enabled: false
  max_output_bytes: 1048576
  command_timeout_seconds: 120
  secret_path_denylist: [".env", "credentials.json", "id_rsa"]
  investigation:
    large_file_bytes: 524288
    max_grep_output_bytes: 262144
    command_timeout_seconds: 120
    sensitive_globs: ["*.pem", ".git/*"]

policies

Repo-weite Leitplanken: sauberes Git, Secret-Dateimuster, Limits geänderter Dateien, Netzwerk und Labels, die vor bestimmten Änderungsklassen eine menschliche Freigabe erzwingen.

policies:
  require_clean_git: true
  forbid_untracked_secret_files: true
  max_files_changed_per_task: 20
  allow_network: false
  require_human_approval_for:
    - database_migration
    - security_sensitive_change
    - dependency_upgrade

Änderungen prüfen

Nach YAML-Änderungen schnell mit agentflow doctor prüfen, bevor work echte Agents startet.

agentflow doctor