The user has submitted UI feedback changes via the iterate overlay. Your job is to fetch, understand, and implement every pending change.
Tools
Use the MCP tools below. If MCP tools are not available (e.g. the server isn't connected), fall back to the daemon's REST API at http://localhost:4000:
| MCP tool | REST equivalent |
|---|---|
iterate_get_pending_batch | GET /api/changes/pending |
iterate_start_change | PATCH /api/changes/{id}/start |
iterate_implement_change | PATCH /api/changes/{id}/implement |
iterate_implement_dom_change | DELETE /api/dom-changes/{id} |
iterate_list_iterations | GET /api/iterations |
- Start:
PATCH /api/changes/{id}/start— no body needed - Implement change:
PATCH /api/changes/{id}/implement— body:{"summary": "what you changed"} - Implement DOM change:
DELETE /api/dom-changes/{id}— no body needed
Steps
- Fetch the pending batch. Call
iterate_get_pending_batchto retrieve all pending changes and DOM changes. If there are no pending items, tell the user there's nothing to implement and stop. - Start each change. For every change, call
iterate_start_changewith its ID so the overlay UI reflects that you've started working on it. - Plan your changes. Group changes by source file. Each change includes:
- sourceLocation — the file and line number (e.g. src/components/Hero.tsx:42) - componentName — the React component name - comment — what the user wants changed - elements — selected DOM elements with selectors, styles, and layout info - textSelection — highlighted text if applicable - DOM changes — any elements the user dragged to new positions
- Read source files. For each unique
sourceLocation, read the file to understand the current code before making changes. - Implement the changes. Work through each change:
- Make changes in the correct iteration worktree — the change's iteration field tells you which worktree the change belongs to - IMPORTANT: Worktrees are full repository checkouts. The worktree path points to the repo root, NOT the app subdirectory. If the app lives at examples/next-app/ in the repo, you must edit files at {worktreePath}/examples/next-app/src/..., not {worktreePath}/src/.... Always use the sourceLocation path relative to the worktree root. - DOM changes describe structural layout changes the user made by dragging elements. Each DOM change has a type field: - reorder — the user reordered an element within the same parent container (e.g. a flex/grid layout). The before.siblingIndex and after.siblingIndex tell you the element's position among its siblings before and after. Implement this by reordering the JSX children in the source code. - reorder with targetParentSelector — cross-parent move. The element was dragged from one container (parentSelector) to another (targetParentSelector). Move the JSX element from the source parent to the destination parent at after.siblingIndex. - move — the user repositioned an element visually. The before.rect and after.rect give bounding box coordinates. Translate the delta into CSS/layout changes (margin, position, transform, etc.). - DOM changes include componentName and sourceLocation to help locate the source code, plus selector and parentSelector to identify the elements.
- Resolve each change. After implementing a change, you must mark it as resolved so it's removed from the pending queue. Do not skip this step — unresolved changes will remain in the overlay as pending. Resolve each change immediately after implementing it, not in a batch at the end.
- Regular changes: Call iterate_implement_change with annotationId (the change's id) and reply (a brief summary shown in the overlay UI). - DOM changes: Call iterate_implement_dom_change with id (the DOM change's id) and optionally reply. DOM changes have their own IDs shown in the pending batch output — they are resolved separately from regular changes.
- Summarize. After resolving all changes, give the user a brief summary of what you changed. The dev server will hot-reload automatically so they can see the results immediately in the browser.