Implementation Settings

Tune /prflow:implement behavior and coordinate verification when multiple agents share the same checkout.

Implementation Settings

Setting	Type and accepted values	Fallback or scaffold	Tier and security note	Example
`prflow_implement.effort`	`low`, `medium`, `high`, `xhigh` or `max`	Scaffold: `low`; absent runtime fallback: `high`	Cloud implementation only. A local `/prflow:implement` run uses the session’s effort; see Recommended Models and Effort. Higher values can increase cost and latency.	`"effort": "low"`
`prflow_implement.implement_pr_state`	`ready_for_review` or `draft`	`ready_for_review`; invalid values also publish	Implementation. `draft` leaves the completed pull request for a human to publish. PRFlow never merges it.	`"implement_pr_state": "draft"`
`prflow_implement.update_branch_checkpoints`	Boolean	`true`; only an explicit false disables	Implementation and pushed fix-loop checkpoints. Merges the configured base into the feature branch at defined boundaries. When false, the final workpad checkpoint row records that the branch was not reconciled with its base and repeats the freshness the branch setup measured, rather than calling the checkpoint clean.	`"update_branch_checkpoints": true`
`prflow_implement.ci_verification.enabled`	Boolean	`false`; only an explicit JSON true enables	Cloud implementation. When true and the deployment check passes, a full-suite boundary dispatches `ci.yml` for the pushed commit instead of running the suite on the implementation host. `ci-verification-request.py wait` then polls that run. A failed wait prints `failed-job:` and `recap:` lines after `FAILED` (or `recap-status: unestablished`). `ci-verification-request.py request` refuses, before dispatching, a head SHA that is not the checkout’s current commit. Default off. A repository that does not ship the matching `ci.yml` inputs sees no effect.	`"ci_verification": { "enabled": true }`
`prflow_implement.ci_verification.pre_request_checks`	Array of commands, each a non-empty array of strings (argv, no shell)	`[]`; opt-in	Cloud implementation with CI verification enabled. Before dispatching a new CI run, `ci-verification-request.py request` runs each command in order from the repository root, launching a `.py` first entry with Python, and refuses the request (`REFUSED pre-request-check-failed`) when one exits non-zero, unless the same failure reproduces at the merge-base with the base branch. A command that cannot start, runs past the helper’s time limit, or a malformed value refuses as `pre-request-check-unavailable`. To gate on the changed-file lint, list the vendored `[".prflow/vendor/prflow/scripts/preflight.py", "lint-changed", "--fail-on-findings"]`.	`"pre_request_checks": [[".prflow/vendor/prflow/scripts/preflight.py", "lint-changed", "--fail-on-findings"]]`
`prflow.publish_model_effort`	Boolean	`true`; only an explicit JSON false disables	Governs the provenance line for every command that emits one — the `/prflow:implement` draft pull request and the `/prflow:spec` issue alike: when false the line names the plugin version alone, suppressing the model and effort clause. The version is always published. Only the JSON boolean `false` disables it; the string `"false"` and the array `[false]` do not. Supersedes the former per-command key in the `prflow_implement` section, which is now read by nothing.	`"publish_model_effort": true`
`prflow_implement.stall_backstop.enabled`	Boolean	`true`; unrecognized values enable	Cloud implementation. When false, an interim run can end without an automatic resume or loud failure.	`"enabled": true`
`prflow_implement.stall_backstop.max_resume_attempts`	Integer zero or greater	`2`; invalid values use `2`	Cloud implementation. `0` detects and fails without resuming. Each resume can incur another run.	`"max_resume_attempts": 2`
`prflow_implement.stall_backstop.defer_to_runner_retry`	Boolean	`false`; only the JSON boolean `true` enables	Cloud implementation on a runner that retries a failed job on its own (for example RunsOn `retry=when-interrupted`). Controls only an unclassifiable failed agent step (a reclaimed or dead job): when true it is left to the runner’s retry with one informational comment; when false the backstop resumes it, or marks the run 💥 Failed when the resume cannot proceed. A cancelled job is unaffected. Leave false on a runner without job-level retry. See Cloud Recovery.	`"defer_to_runner_retry": false`
`prflow_implement.spot_interruption_watcher.enabled`	Boolean	`false`; only the JSON boolean `true` enables	Cloud implementation on a Linux EC2 Spot runner. Opt-in: a background watcher detects a Spot reclaim, records a durable marker, and a downstream recovery job resumes the run on the same bounded path a stall backstop uses. Only the JSON boolean `true` starts it; the string `"true"` does not. An explicit `false` is logged as disabled by config, not as a wrong type. Off (and safe) on any non-Linux or non-EC2 host. See Cloud Recovery.	`"spot_interruption_watcher": { "enabled": true }`
`prflow.attribute_commits_to_triggerer`	Boolean	Runtime and scaffold: `false`	Cloud writer jobs. Applies only to verified human users and changes Git metadata, not the push credential. Trigger-time and post-merge-only.	`"attribute_commits_to_triggerer": true`
`verification_flight.enabled`	Boolean	`true`	Local implementation and inline review-and-fix. Disabling reuse does not turn a missing or stale record into a pass.	`"enabled": true`
`status_labels.enabled`	Boolean	`true`; only the JSON boolean `false` or the string `"false"` disables	Local and cloud implementation. Mirrors the run’s status onto one managed label — `PRFlow:Implementing`, `PRFlow:Stuck` or `PRFlow:Complete` — on the issue and its open pull request — the pull request carries its `PRFlow:Implementing` label from the moment the run links it, not only once a later status write finds it — so a running or stalled run is visible from the issue and pull-request lists. Each managed label gets a fixed brand color the first time PRFlow creates it (an already-existing label is never re-colored). Best-effort: label errors never change a run’s outcome, and unmanaged labels are left in place.	`"status_labels": { "enabled": true }`

prflow_implement.effort has no default in the schema, so the scaffolded value and the fallback differ. /prflow:init writes "effort": "low". When the key is absent, the shipped implementation workflow resolves it to high, the same fallback prflow.effort uses. Removing the key raises effort rather than lowering it.

preflight.py lint-changed is advisory unless you pass --fail-on-findings, which exits 1 when a linter reports findings and 2 when a linter could not run, and prints LINT-CHANGED findings ops=<ids> naming them, followed by one LINT-CHANGED op=<id> receipt=<path> line per op giving the absolute path of that op’s receipt; when the linter ran, the receipt’s findings field holds its output. A receipt path containing a line break is not printed, and the run exits 2. A ruff outside your lint manifest’s pinned major.minor family reports a different rule set, so its findings never fail the run; it prints LINT-CHANGED unverified ops=<ids> reason=ruff-family-skew reported=<X.Y> pinned=<A.B> instead. Each ruff receipt carries ruff_family as match, skew or unestablished. The summary line ends with ruff-family=<value> using the same distilled result (none when no ruff invocation ran).

prflow.attribute_commits_to_triggerer records the person who triggered the run as the author of the commits PRFlow pushes. It changes Git metadata only. The push still uses the workflow’s own credential, so this setting does not grant or transfer any access. Enable it knowing that a commit will carry a name that did not write the code.

Settings you rarely need to change

Setting	Type and accepted values	Fallback or scaffold	Tier and note	Example
`verification_flight.lease_seconds`	Integer zero or greater	`900`	Reserved for future use. Changing this setting has no effect in the current release.	`"lease_seconds": 900`
`verification_flight.wait_timeout_seconds`	Integer zero or greater	Scaffold: `600`	Reserved for future use. Changing this setting has no effect in the current release.	`"wait_timeout_seconds": 600`

Provider and model overrides for implementation are documented in Model Providers. Implementation tool grants are documented in Tool Permissions. To give implementation runs a repository-specific rule, such as the verification command they must use, write a prompt extension.

Valid Implementation Example

{
  "prflow": {
    "attribute_commits_to_triggerer": false,
    "publish_model_effort": true
  },
  "prflow_implement": {
    "effort": "low",
    "implement_pr_state": "ready_for_review",
    "update_branch_checkpoints": true,
    "stall_backstop": {
      "enabled": true,
      "max_resume_attempts": 2,
      "defer_to_runner_retry": false
    }
  },
  "verification_flight": {
    "enabled": true,
    "lease_seconds": 900,
    "wait_timeout_seconds": 600
  },
  "status_labels": {
    "enabled": true
  }
}

Expected result: a cloud implementation run works at low effort, keeps the feature branch current with the base branch at checkpoints, publishes the finished pull request for review, resumes at most twice if a cloud run stalls, and keeps a PRFlow:Implementing / PRFlow:Stuck / PRFlow:Complete status label in sync on the issue and its pull request.

status_labels.enabled creates the three managed labels in your repository on first use and matches them by exact name, so your bare PRFlow provenance label and any other labels are never touched. Because the label follows the workpad status automatically — including the statuses written after the agent has stopped — a stalled run shows PRFlow:Stuck in the issue list without anyone opening the ticket. Set it to false (or the string "false") to keep exactly today’s behavior, applying no labels.

​Implementation Settings

​Valid Implementation Example

Implementation Settings

Valid Implementation Example