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.

Planning before building

A bug report is concrete — there is a defect and a correct behaviour, so the agent can just fix it. A feature request often is not. Plan before building (Settings → Automation) adds a step between triage and code for the requests that are big or unclear: the agent writes a short plan — what to build, how it would fit your codebase, which files it would touch, what it still needs you to decide, and a rough size — and then stops.

You approve the plan, not the pull request. Nothing is coded until you do.

It is deliberately narrow, because every extra step costs one more run on your own agent account. Only feature requests qualify, and only when one of these is true:

• Triage was unsure — confidence under 65%, so nobody is certain what was being asked for.
• Several people asked — demand of 5 or more, where getting the shape right matters more than speed.
• Triage flagged it for you — if a human needs to weigh in, a written plan beats a diff.

Bug reports never get a plan, however severe or popular. Turn the whole thing off in Settings and features go straight to code exactly as before.

Demand: how many people asked

When triage recognises a new report as a duplicate of something already in your inbox, it does not just file it away — it credits the original. Board upvotes count the same way. Both roll into one number on the item: demand = the original report + its duplicates + its upvotes.

Duplicates are matched against your whole backlog, not just recent items, so a request that keeps coming back over months accumulates instead of scattering. Demand shows on the item and feeds the planning rules above.

Comments on an item

Every item has a comment thread. Add context, correct a wrong classification, or push back on a plan — as many comments as you like, whenever you like. They are read by triage, planning, and the coding agent on their next run.

Writing a comment runs nothing. Re-running triage or planning lives in the item’s ··· menu, so you can think out loud without spending an agent run — then apply it all at once when you are ready. That is also how you fix a plan you disagree with: leave a comment saying why, then hit Plan again.

When triage flags an item for your review, the question appears at the top of the item with a box to answer it. Answer & re-run triage saves your answer to the thread and re-runs in one step.

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:

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.

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.