Quick fix
The Quick fix row handles a set of small, well-understood, independent fixes — two ways. Task (batch) resolves to quick_fix: parse N fixes, understand the app, fan out one sub-agent per fix in parallel, join, validate, and commit per ## Git. Collaborative (live) resolves to quick_fix_collab: a live assistant that already knows the app, to which you send fixes one at a time — it applies and validates each, never auto-commits, and writes its own session record in 4_done/.
A single dropdown row with a Task / Collaborative sub-toggle. The form's effectiveType() resolver maps Task → quick_fix and Collaborative → quick_fix_collab — two distinct backend types behind one row (D-49).
The flow
Pick the mode that matches how you want to work. Both keep the same scope contract — small, independent fixes only — but their flow and output differ.
Task (batch) → quick_fix
An action-layer mini-orchestrator. It parses the mandate into N independent fixes, understands the app once, then fans out one full-context fixer sub-agent per fix in parallel. It joins the results, validates the batch, and commits — and on PR: yes opens the PR (or surfaces the remote-aware fallback) — per the Git section.
Collaborative (live) → quick_fix_collab
A direct-invoked live assistant. It boots once by understanding the app, then waits. You send one fix per turn; it applies the fix, validates it, shows you the diff, and waits again — looping until you send done. It never auto-commits, and it authors its own session record born directly in 4_done/.
What it is for
Both modes are for the common "I have a few small fixes, just do them" case where a full bug per fix is too heavy and the fixes are independent enough to be safe on their own. The contract — small, well-understood, self-contained fixes that need no clarify, brainstorm, plan, or cross-cutting coordination — is identical in both; anything bigger is refused and redirected to a feature or bug.
Pick the mode by how you want to drive the work:
- Task when you already have the full list and want it done in one shot. It runs the fixes in parallel and produces a downloadable intake the orchestrator picks up, plus a committed batch (and an opened PR when
PR: yes) per the Git section. - Collaborative when you'd rather work interactively — discover and send fixes one at a time and review each diff before moving on. It produces a session record in
4_done/and leaves the changed (unstaged) working tree; the assistant suggests, but does not run, the commit command.
PR: yes opens the PR — per ## Git, via the shared git landing (_processes/_shared/git-landing.md, D-63), honouring the before_commit / before_pr gates: the PR targets the resolved PR target branch (blank ⇒ production), and off GitHub the PR is surfaced as a credential-free PR-creation link from the host table (D-82). Merging stays your action in both modes — the workflow never merges a PR.
The logic
The two modes look alike in the form but route very differently behind it.
- Task = action layer, orchestrator-routed. A
quick_fixintake lands in a queue like any other job; the orchestrator's§C.routesees layeractionand hands it to_processes/03_action/quick_fix/quick_fix.prompt.mdinstead of entering the stage loop. The Git section drives commit / PR and honours thebefore_commit/before_prgates. - Collaborative = operation op-card, direct-invoked.
quick_fix_collabis not orchestrator-routed and has noJOB.mdintake — you start it by sending its prompt path directly. It authors its own session record born directly in4_done/, a scoped carve-out from the orchestrator's sole-4_done-mover invariant (D-49).
In the form, the sub-toggle's effectiveType() resolver maps Task → quick_fix (an action-layer intake) and Collaborative → quick_fix_collab (a copy-the-prompt-path op-card, nothing queued). Both remain distinct registry / closed-vocabulary types — the merge is presentation-only.
The fields
The two modes carry different config because they run differently.
Task (batch)
A quick_fix JOB.md carries the header, a ## Git block, and the mandate — and no ## Stages, ## Approval gates, or ## Per-stage config (it is routed by layer, not by enabled stages).
| Field | What it sets |
|---|---|
| Mandate | The list of N independent small fixes — one list item per fix. |
## Git | Create branch / Validate against main / Commit / Push / PR (preset all yes) and PR target branch (blank ⇒ production; 0.14, D-63), plus the git approval gates before_commit / before_pr (preset off). |
Collaborative (live)
An op-card carries no stage, gate, or action config — the fixes are sent live, one per turn, not declared up front. There is no intake to fill; you just copy the prompt path.
| Field | What it sets |
|---|---|
| (none in the form) | Selecting Collaborative collapses the left column and renders only the op-card. Fixes are sent live in the session; the only configuration is the validation command, which the assistant derives from app.md (or asks once). |
How to run it
Task (batch)
Submit the intake from the form (it lands in jobs/0_new/), then send the orchestrator prompt — it picks the job up and routes it to the quick_fix orchestrator. You can also run the action prompt directly against an existing job.
_processes/02_orchestrator/orchestrator.prompt.md
# or, against an existing quick_fix job:
_processes/03_action/quick_fix/quick_fix.prompt.mdCollaborative (live)
No intake — send the collab prompt path directly. It boots, confirms the app and validation command, then waits for your first fix.
_processes/03_action/quick_fix/collab.prompt.md