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/closed
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 → closed (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 closed. Use only when reports are small and the repo is recoverable (under git, with CI). Pick the interval to match how fast feedback arrives.

Auto-fix needs a safety net

Unattended close means no human reviews the diff. Only run it where a bad change is cheap to revert — a git repo with CI, never a non-versioned prod app. Otherwise use Continuous — propose.

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.

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.