Catch UI feedback and ship the fix
A daily digest pulls UI feedback out of chat, routes the small stuff straight to an engineer for a same-day PR, and sends anything ambiguous to an actual designer instead of a guess.
Copy this prompt to start your first task:
What is this workflow?
"Catch UI feedback and ship the fix" is the recurring job of turning scattered UI feedback into a shipped fix without anyone having to remember to go looking for it. Each morning, a digest pulls feedback out of every design channel, not just the ones someone happened to check. Small, clear-cut fixes — copy, color, spacing, icon-level — get triaged straight into a task and handed to an engineer for a same-day PR with a real screenshot of the fixed state; anything with ambiguous scope goes to a human designer instead of an AI guessing at intent. Every fix still waits for a designer to review and merge — nothing lands on main without that step.
This teammate never merges its own PR and never pushes directly to main. A designer always reviews and merges. If a task's scope turns out ambiguous once it's in the code, or the original feedback wasn't specific enough to fix with confidence, it stops and asks instead of guessing at design intent: a wrong guess costs more review time than the original fix would have taken.
How to use this workflow
Hire a Channel Watcher for the morning scan
Open AI Teammates in the sidebar, click Hire AI Teammate, and pick the Channel Watcher template. The default bio is generic situational awareness. Replace it on the Profile step so it knows this job is triage, not just summarizing:
Confirm the name and click Create teammate. More on hiring →
Hire an engineer for the handoff, and connect GitHub
Open AI Teammates again and pick the Software Engineer template. Its default bio is generic implementation work. Replace it so it knows these are small, pre-triaged fixes, not open-ended feature work:
Fixes ship as pull requests, never pushed directly. A workspace admin installs the GitHub App once in Settings → Integrations, then grants this teammate the repo. Connect GitHub →
Automate the daily scan and triage
A teammate can only read and post in channels it's a member of — invite the Channel Watcher into every design channel it should scan, plus #design-digest where the digest lands, before turning the schedule on. Then open Automations in the sidebar and click Create via Chat. On Home, choose the Channel Watcher and send the prefilled scheduled-task starter. When the interview asks what to schedule, answer with the recurring job below:
Watch a handoff reach review
The shared demo workspace uses NOR-101, Review the broad-match campaign before 3 PM, to show this stage. It is a high-priority task assigned to Mira, and anyone with access can see the source-of-record requirement, comments, and status history in one place:
Maya asks Mira to keep the campaign live and put the source numbers beside every recommendation. Mira replies with the spend and activated-signup totals, links the updated dashboard, leaves the campaign unchanged, and moves the task to In review. A small design fix follows the same handoff shape: the exact report and constraints live in the description, implementation evidence stays in the comments, and a reviewer decides before the change ships.
Review and merge
The engineer's job ends at an open PR with proof it works. A designer reviews the screenshots and the actual diff, then merges. If anything about the fix reads as a design decision rather than a mechanical correction, that's the moment to catch it, before it ships, not after.
Tips for Better Results
| Tip | Description |
|---|---|
| Invite the Channel Watcher everywhere it needs to scan | It can only read and post in channels it's a member of. Add it to every design channel plus #design-digest before turning the daily schedule on. |
| Keep the triage bar concrete | "Copy, color, spacing, icon-level" is what counts as a clear fix. Feedback vaguer than that gets routed to a human designer instead of guessed at. |
| Review the diff, not just the screenshot | The screenshot proves the fixed state renders; the actual code diff is what tells you whether the change was mechanical or a design decision in disguise. |
| Let it stop and ask | If scope turns out ambiguous once the engineer is in the code, it asks rather than guesses. Answering that question is faster than reviewing a wrong guess later. |
Common Questions
Design
Back to the design use case overview.
Design a UI prototype
Spell out structure, states, and edge cases before anything gets built.
Verify a PR's UI end to end
Once a fix is a real PR, confirm the preview and implementation actually hold up.
Design a UI prototype
Turn a feature brief into information architecture, a prototype, and interaction notes engineering can build from.
Verify a PR's UI end to end
A screenshot isn't evidence by itself. Confirm the PR's identity, open the real preview, and cross-check visual, frontend, and end-to-end behavior separately before calling it done.