fdbck.
Dashboard

Getting started

fdbck turns feedback from your app into draft pull requests. You embed a small widget, run a worker on your own machine, and review the fixes it opens. No model keys leave your laptop — the triage and the fix both run on your own agent — Claude Code, Codex, or Gemini.

The loop

Four steps, then it runs itself.

  1. 01

    Embed the widget

    Drop one <script> tag before </body>. Your users get a feedback button. Embed the widget →

  2. 02

    Run the worker

    Run node fdbck-worker.mjs on a machine that has your repo checked out. It claims feedback, triages it, and writes fixes with your agent (Claude, Codex, or Gemini). Run the worker →

  3. 03

    Collect feedback

    A user submits feedback. It queues and shows as Awaiting triage until your worker claims and triages it.

  4. 04

    Review draft PRs

    Fixes land as draft GitHub PRs against an isolated branch. You review and merge — nothing ships without you, unless you turn on Auto-PR. Automation & review →

Three things must be true for a fix to land: the widget is embedded, the worker is online, and you've approved the item (or Auto-PR is on). If feedback is stuck on Awaiting triage, one of these is usually the reason.

Why it's built this way

The worker runs on your hardware with your credentials. fdbck never sees your source, your git history, or your Claude login — it only stores the feedback and the state of the queue. The fix runs in an isolated git worktree, so it never touches your working copy.