Apply comments

/apply-comments is the other half of the inspector. The inspector writes what you asked for into the source as @slide-comment markers; this skill reads them back and does the work.

It ships with the scaffold, so any agent pointed at the workspace can call it — Claude Code, Codex, Cursor, and the rest.

What a run does

1. Finds every @slide-comment marker under slides/.
2. For each one, reads the note and the code it is anchored to.
3. Edits that code to satisfy the note.
4. Deletes the marker.

› /apply-comments
✓ 3 notes · slides/q2-launch/index.tsx
✓ 1 note  · slides/vector-search/pages/04-latency.tsx

The edits are scoped to the flagged regions. A note about a heading on page four does not become a rewrite of page four, which is what makes it safe to leave a dozen of them lying around.

Batching is the point

Applying one note at a time works and is a waste of a round trip. The rhythm that pays off is: walk the deck the way an audience will see it, flag whatever snags without stopping to fix it, and hand the whole set over at the end.

present → flag as you go → /apply-comments → walk it again

You get through the deck once without breaking your own attention, and the agent gets the notes as a set — which sometimes matters, because three notes that all say "too busy" are one problem rather than three.

When a note comes back unapplied

If a note is ambiguous, the agent leaves the marker where it is and says why rather than guessing. That is the intended behaviour: a wrong edit is more expensive than a skipped one, because you have to notice it first.

Notes that fail this way are usually missing a target — "make this bigger" where the panel had two candidate elements selected, or "match the other page" without saying which one. Rewrite the note with the specific and re-run.