Imported from rossboyd/quickque (.codex/.tmp/plugins/plugins/canva/skills/canva-implement-feedback/SKILL.md). Install upstream with npx skills add rossboyd/quickque --skill canva-implement-feedback. Copyright stays with the author.

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