Configuration - PRFlow

Start here to find out what PRFlow reads from your repository and which page documents the setting you need.

Where Configuration Lives

PRFlow reads one file: .prflow/config.json at the root of your repository. It is plain JSON and it is committed, so your whole team and every cloud run see the same values. Two other files sit beside it and are not settings:

.prflow/config.example.json is the scaffolded reference copy. It shows the shape of every section.
.prflow/skill-extensions/ holds prompt extensions, which are instructions rather than values.

Run /prflow:init to create the file. It writes the file when it is absent and adds newly scaffolded keys to an existing file without replacing values or arrays you already set.

When You Need a Config File

Local Runs

Work with no config file at all. Every setting falls back to a built-in default. Add the file when you want to change one.

Cloud Runs

Require the file, committed to your default branch. A cloud workflow reads it to decide whether it may run at all.

Cloud workflows resolve their settings from the default branch at the moment a run is triggered. A pull request that changes such a setting does not change its own run. The new value applies after the pull request merges.

A Starter Config

This is a complete, valid config file. It enables the cloud workflow, names the base branch and grants one test command to the implementation path:

{
  "$schema": "./config.schema.json",
  "base_branch": "main",
  "claude_model": "claude-opus-5",
  "prflow_implement": {
    "allowed_tools": [
      "Bash(npm test:*)"
    ]
  },
  "workflows": {
    "prflow": true
  }
}

Expected result: local commands keep working exactly as before, cloud runs are enabled for authorized users and a cloud implementation run may invoke npm test. Every key not listed keeps its default.

Setting Families

All Settings A to Z

Every setting name in alphabetical order with the page that documents it. Start here when you know the key.

Core Settings

Base branch, model, who may trigger a cloud run and which workflows are enabled.

Implementation

Pull request state, branch checkpoints, stall handling and verification reuse.

Review

Verdict thresholds, fix routing, progress comments and retained legacy settings.

Review Agents

Per-agent model, effort and iteration overrides inside the review engine.

Skill Extensions

Your team’s own instructions, appended to a command on every run.

Model Providers

Route cloud execution through a gateway or Amazon Bedrock.

Runtime Setup

Languages, service containers and install commands for the cloud runner.

Tool Permissions

The repository commands a cloud agent is allowed to run.

Documentation and Retrospectives

Documentation paths, deferred-issue labels and weekly retrospective limits.

Observability and Privacy

Diagnostics, transcript artifacts, denied-command records and telemetry storage.

Treat Configuration as Code

Several settings decide what a cloud agent may run and who may start it. prflow.allowed_users, every allowed_tools array and every setup.install line grant execution or access. Review a change to them as carefully as a change to a workflow file.

Validate the JSON before you commit it. Cloud config loading checks that the file is valid JSON, but it does not run a full schema check, so a misspelled key can pass unnoticed and leave the default in place. Next: find your setting in All Settings A to Z, or read Core Settings first if you are setting the file up for the first time.

​Where Configuration Lives

​When You Need a Config File

Local Runs

Cloud Runs

​A Starter Config

​Setting Families

All Settings A to Z

Core Settings

Implementation

Review

Review Agents

Skill Extensions

Model Providers

Runtime Setup

Tool Permissions

Documentation and Retrospectives

Observability and Privacy

​Treat Configuration as Code

Where Configuration Lives

When You Need a Config File

A Starter Config

Setting Families

Treat Configuration as Code