agentsclimarketplace

Converting files

Skill oaustegard/claude-skills/converting-files

My collection of Claude skills

Install
npx -y skills add oaustegard/claude-skills --skill converting-files

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Convert a file from one format to another inside the container — documents, images, audio, video. Routes to the right engine (pandoc, LibreOffice, ImageMagick, ffmpeg) by format pair. Triggers on "convert X to Y", "turn this docx into a pdf", "make a gif from this mp4", "md to docx", "batch-convert these images", or any single-file or batch format change where the source and target extensions differ. NOT for editing content (use docx/pptx/xlsx/pdf skills), creating files from scratch, or reading a file you already have in context.

SKILL.md

6.5 KB, as published. Nobody here has run it

converting-files

Four conversion engines are already in this container — pandoc, libreoffice (headless), ImageMagick's convert, and ffmpeg. The hard part isn't running them; it's picking the right one. pandoc mangles a real .docx into PDF; LibreOffice is the tool for that. pandoc is better than LibreOffice for md → docx. Neither touches mp4 → gif. This skill encodes that routing so the choice isn't re-derived (often wrongly) each time.

scripts/convert.py is a dispatcher over those four binaries, not a new engine. Use it for the common cases; drop to the raw engine when you need flags it doesn't pass through.

Is this the right skill?

You want to…Use instead
Change a file's format (ext A → ext B)this skill
Edit/author a Word/PPT/Excel/PDF's contentdocx / pptx / xlsx / pdf skills
Read a file already shown in contextjust read it — no conversion
Extract text/tables from a PDFpdf-reading skill
Fill or merge PDFspdf skill

Format change = here. Content change = a content skill. A docx → pdf is a format change; "fix the grammar in this docx" is not.

Engine routing (the actual content of this skill)

Source family → target family decides the engine. The dispatcher applies this; the table is here so the reasoning is auditable and so you can call the engine directly when needed.

From → ToEngineWhy
markup → markup (md, html, rst, latex, org, epub, rtf, ipynb…)pandocwhat it's built for
markup → Office (md → docx/pptx/odt)pandoccleaner than LibreOffice from markup
Office → markup (docx/odt/pptx → md/html…)pandocreads modern OOXML well
Office → PDF (docx/pptx/xlsx → pdf)LibreOfficepreserves layout; pandoc mangles it
Office ↔ Office, or legacy (.doc/.ppt/.xls) anythingLibreOfficepandoc can't read legacy binary formats at all
markup → PDF (md → pdf)pandoc (+pdflatex/xelatex)lighter than LibreOffice for plain markup
image ↔ image (png, jpg, gif, webp, tiff, heic, svg…)ImageMagickconvert in out
image → PDFImageMagick
audio ↔ audio (mp3, wav, flac, ogg, aac, m4a, opus…)ffmpeg
video ↔ video, mp4 → gif, gif → mp4ffmpeggif-from-video is an ffmpeg job, not ImageMagick

gif lives in both image and video worlds: png → gif is ImageMagick (still image), mp4 → gif is ffmpeg (animation). The dispatcher handles the split by the source family.

Usage

# Plan only — print engine + reason + exact command, run nothing. Do this first
# on an unfamiliar pair to confirm the route before committing.
python3 /mnt/skills/user/converting-files/scripts/convert.py --plan in.docx out.pdf

# Convert.
python3 /mnt/skills/user/converting-files/scripts/convert.py in.docx out.pdf
python3 /mnt/skills/user/converting-files/scripts/convert.py notes.md notes.docx
python3 /mnt/skills/user/converting-files/scripts/convert.py clip.mp4 clip.gif

# Pass engine flags through (everything after OUTPUT goes to the engine):
python3 .../convert.py photo.png photo.jpg -quality 85         # ImageMagick
python3 .../convert.py song.wav song.mp3 -b:a 192k             # ffmpeg
python3 .../convert.py paper.md paper.pdf --pdf-engine=xelatex # pandoc

# Force a specific engine if you disagree with the route:
python3 .../convert.py weird.docx weird.md --engine pandoc

Exit codes: 0 ok, 2 no route exists, 3 engine failed (stderr tail printed), 4 bad args / missing input.

Batch

The dispatcher is one file at a time by design — batch is a shell loop so each file's failure is visible:

for f in *.png; do
  python3 /mnt/skills/user/converting-files/scripts/convert.py "$f" "${f%.png}.webp" || echo "FAILED: $f"
done

Gotchas (the things that cost a re-run)

  • LibreOffice names the output itself — it writes <input-stem>.<ext> into --outdir, ignoring your chosen filename. The dispatcher renames to your OUTPUT after. If you call libreoffice raw, expect the input-stem name.
  • LibreOffice headless is single-instance. Two concurrent --headless calls collide on the user profile and one silently does nothing. Run them serially (the batch loop above is serial — fine).
  • markup → pdf needs a LaTeX engine. pdflatex/xelatex are present, but exotic Unicode wants --pdf-engine=xelatex. If LaTeX chokes on the content, route through docx first: md → docx (pandoc) then docx → pdf (LibreOffice).
  • ImageMagick here is IM6 (convert, not magick). Policy may block some formats; if convert refuses a PDF/PS op, that's the /etc/ImageMagick-6/policy.xml security policy, not a missing codec.
  • markup → jira emits heading anchors. md → jira works (both are pandoc formats), but headings come out as h1. {anchor:slug}Title — pandoc materializing the auto-generated heading ID. Suppress with --engine pandoc ... -f markdown-auto_identifiers (pass the format-with-extension yourself, since the dispatcher infers a bare markdown).
  • --plan lies about nothing but runs nothing — it can't tell you the content will survive (e.g. a pptx → md drops all layout). Plan checks the route; only a real run checks the result.

Why not VERT (or any web converter) as the skill

VERT (vert.sh) is a Svelte/WASM browser app wrapping these same engines (libvips, ffmpeg.wasm, Pandoc-wasm) for a human at a tab who wants local privacy. There's no library or CLI to import — the app is the UI. In-container we already have the native binaries with full filesystem access and no browser memory ceiling, so the WASM wrappers would be strictly slower and weaker. VERT is a good recommendation to a person; it's the wrong shape for a skill. This skill is the in-container equivalent of what VERT does in a tab.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.