Workflow modes

Once a project is set up, the patchrooms-feedback skill pulls reports and acts on them. How it acts is the workflow mode. Pick one with the user up front — autonomy is a spectrum, and the right point depends on how reversible a wrong fix is (is the repo under git? is there CI? is it a prod app or a preview?).

The modes

Mode	When	Autonomy	Closes reports?
Review (one-shot)	You’re actively working; user says “pull feedback”	Fix + show diff, wait	No — user confirms
Test pass	Validate a release against filed reports	Verify each, no code edits	Marks `triaged`/`fixed`
Timed loop — auto-fix	Steady stream of small, low-risk reports	Fix and close unattended	Yes
Continuous — propose	Backlog burn-down with a human in the loop	Fix on a branch, surface diffs	No
Spec-writing	Reports are large/ambiguous	Turn each into a spec/plan, no fix	No
Accumulate & ask	You keep hitting unknowns	Collect questions, batch them back	No

Review (one-shot)

The default. The user says “pull feedback”; you list_reports --status new, get each, fix following repo conventions, run the project’s type-check/lint, set the report to in-progress, and show the diff. Close only after the user confirms.

Test pass

Use the open reports as a QA checklist for a release. For each, reproduce on the page URL, confirm whether it’s still broken, and set_status → fixed or triaged (still open, needs work). No code edits — this mode reports, it doesn’t patch.

Timed loop — auto-fix

A recurring pull that fixes and closes without waiting. In Claude Code:

/loop 5m /patchrooms-feedback full-auto

Each tick: list_reports --status new → if empty, wait; else get, fix, verify, set_status fixed. Use only when reports are small and the repo is recoverable (under git, with CI). Pick the interval to match how fast feedback arrives.

Continuous — propose

Same loop, but fixes land on a branch and reports stay in-progress with the diff surfaced for review. Good for burning down a backlog while a human approves batches.

/loop 15m /patchrooms-feedback propose

Spec-writing

When a report is too big or vague to fix directly, don’t guess. Convert it into a short spec or plan (what’s being asked, affected screens/code, acceptance check), write it to the repo (e.g. docs/plans/), and leave the report triaged with a note. The user reviews the spec before any code is written.

Accumulate & ask

When you keep hitting unknowns (missing context, product decisions), don’t stall on each one. Collect the open questions across the reports you triaged, then surface them to the user in one batch — a summary message, or filed back as a report on the project — instead of one interruption per report.

Replying in a thread: drafts by default

Whatever the mode, add_comment saves your reply as a draft unless you say otherwise. A draft is visible only in the dashboard, where the person reviews it and publishes it as you, edits it first, or publishes it under their own name. Nothing reaches the thread until they act — so a wrong reply costs a click, not a conversation with the client.

Pass draft: false only when there’s no human in the loop to approve it (a timed auto-fix loop) or when the user explicitly asked you to post live.

Label each reply with kind so a batch stays skimmable: fix for a change you already made, question when you need an answer to proceed, options when you’re laying out alternatives with tradeoffs instead of picking one, deferral when you’re proposing to postpone with a reason, techdebt when the honest answer is “this is expensive because of X”. A person triaging ten replies can then read every question first and unblock you in one pass.

Choosing autonomy

Start at the least autonomous mode that fits and move up only with the user’s say-so. A useful default ladder: Review → Continuous-propose → Timed auto-fix, gated on “is a wrong fix cheap to undo here?”. For anything ambiguous, drop to Spec-writing or Accumulate & ask rather than fixing on a guess.