canva-implement-feedback

What this skill does

# Feedback to Finished

A deck has been out for review — stakeholders have left comments scattered across slides. This skill reads every thread, summarises what reviewers actually want, makes the clear-cut changes directly, and flags anything ambiguous for a human decision.

## Canva Editing API — What You Can and Cannot Do

Before triaging feedback, you MUST know these constraints. This avoids wasted back-and-forth with the user on changes that are impossible via the API.

### What the API CAN do (via `perform-editing-operations`)

- **Text content**: replace entire text elements (`replace_text`), find-and-replace substrings (`find_and_replace_text`)
- **Text formatting**: font size, font weight (bold), font style (italic), text color, text alignment, line height, text decoration (underline), strikethrough, links, list formatting
- **Media**: replace images/videos (`update_fill`), insert new images/videos (`insert_fill`), delete elements (`delete_element`)
- **Layout**: reposition elements (`position_element`), resize elements (`resize_element`)
- **Metadata**: update design title (`update_title`)

### What the API CANNOT do

- Change font family/typeface — only size, weight, and style are supported
- Add new text elements — you can only insert media (images/videos), not new text boxes
- Change background colors or gradients
- Add, remove, or reorder pages/slides
- Modify animations or transitions
- Change element opacity (except on newly inserted fills)
- Group/ungroup elements
- Modify shapes (color, border, etc.) — only text within shapes can be edited

### Triage rule

When a comment requests something in the "CANNOT do" list, classify it as **Requires manual action**. Don't dwell on the limitation — simply note it in the summary and move on. These are normal; most design reviews will have a mix of API-supported and manual changes. Save the details for the manual changes checklist at the end (Step 7).

## Workflow

### Step 1: Resolve the Design

- If the user provides a short link (`canva.link`), call `Canva:resolve-shortlink` to get the design URL
- If the user provides a full Canva URL, extract the design ID from the URL
- If the user provides a **design ID** directly (typically starts with `D`, e.g. `DABcd1234ef`), use it as `design_id`; **do not** use `Canva:search-designs` for a raw ID
- Otherwise ask for the design ID or link

### Step 2: Read All Feedback

- Call `Canva:list-comments` with the design ID to get every comment thread
- For each thread with replies, call `Canva:list-replies` to capture the full conversation
- Call `Canva:get-design-content` to read the current text on every page

### Step 3: Triage the Feedback

Classify each comment thread into one of these categories:

- **Actionable** — a change that the API supports and you can reasonably interpret. Use your best judgement — if a comment says "make the title punchier", rewrite it to be punchier rather than flagging it as ambiguous. If a comment says "fix the spacing", look at the design content and make a reasonable adjustment. Only escalate to the user when you genuinely cannot determine what the reviewer intends (e.g., two reviewers directly contradict each other, or a comment references something you can't find in the design).
- **Requires manual action** — the reviewer wants something the API cannot do (font family change, new text element, background change, page reorder, etc.). Note these briefly in the summary — full details go in the manual changes checklist (Step 7).
- **Resolved** — already addressed, explicitly marked done, or is a positive acknowledgement (e.g., "LGTM", "looks good")

Present a summary to the user organised by category: what you plan to change, what needs clarification, what must be done manually, and what you're skipping.

### Step 4: Get User Approval — ONE time only

- Present the plan and wait for the user to approve
- If the user wants adjustments, update the plan and confirm once more

**This is the only confirmation point in the entire workflow. Once the user says yes, go.**

### Step 5: Apply and Commit the Changes

**Do NOT ask the user again.** They already approved. Execute all of these in sequence immediately:

- Call `Canva:start-editing-transaction` to begin an editing session
- Call `Canva:perform-editing-operations` to make each approved change (batch all operations in a single call where possible)
- Call `Canva:commit-editing-transaction` to save — do NOT ask "shall I commit?" or "ready to save?"
- Show the thumbnail from the editing response to the user as confirmation

### Step 7: Present Remaining Manual Changes

After committing (or if no API-supported changes were possible), present a clear checklist of everything that still needs to be done manually in the Canva editor:

```
## Changes to make manually in Canva

1. **Slide 3 — Change heading font to Montserrat**
   Reviewer: @Sarah | Why: API cannot change font family
   → Open slide 3, select the heading, change font to Montserrat

2. **Slide 7 — Add a new text box for the disclaimer**
   Reviewer: @James | Why: API cannot add new text elements
   → Add a text box below the chart with: "Source: Q3 2025 internal data"

3. ...
```

Include the slide number, what to change, who requested it, and step-by-step instructions so the user can work through the list quickly.

### Step 8: Resolve Comment Threads

- After committing, call `Canva:reply-to-comment` on each actionable thread to note what was changed
- For "Requires manual action" threads, reply noting what was done as the closest alternative and what still needs manual attention
- This closes the feedback loop so reviewers can see their comments were addressed

## Rules

- Be helpful, not cautious — interpret feedback generously and make your best attempt at a change rather than labelling it "ambiguous" and giving up. The user can always reject your changes in the approval step.
- Only escalate to the user when you genuinely can't figure out the intent — two reviewers directly contradict each other, or a comment references something you can't find in the design
- When reviewers disagree, present both sides and let the user decide
- Show the summary of planned changes and wait for approval ONCE — after that, execute everything without further confirmation
- NEVER ask "shall I commit?", "ready to save?", or any variation — the user's initial approval covers the entire edit-and-commit flow
- Manual changes are normal and expected — don't over-explain or apologise for API limitations, just include them in the checklist
- Batch operations: use a single `perform-editing-operations` call with multiple operations rather than one call per change