pptx skill: visual-QA guidance can close a user's open PowerPoint (COM Quit() on the shared instance)

(below from Claude, basically visual verification of a generated slide closed all PowerPoint files, not just the Claude generated one)

The pptx skill documents visual QA via LibreOffice (scripts/office/soffice.py + pdftoppm). On Windows machines without LibreOffice installed, there's no documented fallback, which invites driving the locally-installed PowerPoint via COM automation to render a preview.

That's dangerous: PowerPoint is a single shared COM instance, so New-Object -ComObject PowerPoint.Application attaches to the user's already-running PowerPoint, and calling .Quit() closes the entire application — taking all of the user's open (and possibly unsaved) presentations with it. This just happened to me and cost a user their open files.

Requested changes:

Add an explicit warning in the SKILL/render section: never automate a locally-installed Office app (PowerPoint/Word/Excel) to render or convert; if you must use COM, never call Quit()/Close() on a shared instance.
Document a safe Windows fallback when LibreOffice is absent (e.g., install LibreOffice, or skip visual QA rather than driving the user's Office app), mirroring the existing "bare soffice hangs" guidance.
Environment: Windows, no LibreOffice; Microsoft PowerPoint installed.

Start in the pptx skill's SKILL/render section and review the existing LibreOffice guidance, including scripts/office/soffice.py and the note about bare soffice hangs. Add the warning against automating locally installed Office apps and document installing LibreOffice or skipping visual QA when it is unavailable; done means the Windows fallback does not encourage closing a shared Office instance.

Scritto dal modello di indicizzazione a partire dal testo della issue.