Automation & review
Every item is triaged before anything is attempted. From there, two settings decide how much happens on its own — the Auto-PR gate and Auto-merge. The defaults keep you in the loop; you can loosen them as you build trust.
Triage
When the worker claims an item, it runs your configured agent to classify it before writing any code:
- Type — bug, feature request, or other.
- Severity — 1 to 5, how much it matters.
- Confidence — 0 to 1, how sure triage is that the report is clearly actionable.
These numbers are what the Auto-PR gate reads.
The Auto-PR gate
An item is only worth a fix attempt if triage is confident enough and the issue matters enough. The gate is two thresholds: a minimum confidence (0–1) and a minimum severity (1–5). An item must clear both. Three presets cover most teams:
| Preset | Confidence | Min severity | Feel |
|---|---|---|---|
| Conservative | 0.90 | 4 | Only the clear, high-impact fixes. Fewest PRs, fewest surprises. |
| Balanced | 0.80 | 3 | A sensible default. Attempts most real bugs, skips the vague ones. |
| Aggressive | 0.65 | 2 | Casts a wide net. More PRs to review, including some that miss. |
You can also set custom values under Advanced. Both bugs and feature requests can clear the Auto-PR gate and get a draft PR. An item that doesn't clear it isn't discarded — it sits in your queue as triaged (or deferred, if its confidence was very low), waiting for you to decide.
Review before opening
With Review before opening on, a cleared item is still fixed in an isolated worktree — but instead of opening a PR, the worker parks the diff for your approval. The item shows as Awaiting review; you see the exact proposed changes in the dashboard and either Approve — fdbck opens the draft PR from those exact files, no re-run — or Discard. Nothing hits GitHub until you approve. Good for the first few weeks on a new repo.
With it off, a cleared item opens a draft PR directly — still never a ready-to-merge one, so GitHub's own review is your gate. (If a parked fix would delete a file or is very large, the worker opens the draft PR instead of parking it, so the review is always faithful to the full change.)
Auto-merge
Off by default, and deliberately so. With Auto-merge on, the worker can push a confident bug fix straight to your default branch after CI passes — no human in the loop. It has its own confidence and severity thresholds, separate from and stricter than Auto-PR: the “Balanced” preset merges only at confidence ≥ 0.95, severity ≥ 3 (the defaults), and “Conservative” raises that to 0.97. So an item can clear Auto-PR and still wait for you at the merge step.
Auto-merge has guardrails, but it still ships code without you. Unlike Auto-PR (which will draft a PR for a feature too), auto-merge is bug fixes only, and only those that are ≤ 100 lines and ≤ 3 files, that don't touch any CI/workflow config, YAML file, Dockerfile, Makefile, lockfile, or shell script, that stay within your project root, and only after CI is green. It also requires GitHub's Allow auto-merge setting enabled on the repo. Turn it on only for repos with CI you trust.
What “Awaiting triage” means
A new item shows as Awaiting triage until a worker claims and classifies it. It's not a decision — it means no worker has looked yet. (It's the same lifecycle state a public board surfaces as “Planned.”) If items stay there, your worker is probably offline; check the status pill in Account, or see Troubleshooting.
Choosing your settings
Start at Balanced with Review before opening on and Auto-merge off. Watch a dozen items go by. If the diffs are consistently good, drop Review before opening. Reserve Auto-merge for repos where a bad merge is cheap to revert and CI would catch it anyway.