Skip to main content

​
The file-versioning trap

Anyone who’s shared a deck more than twice knows how it ends: 
Q4_review.pptx
Q4_review_v2.pptx
Q4_review_FINAL.pptx
Q4_review_FINAL_v2.pptx
Q4_review_FINAL_USE_THIS.pptx
Each new version is a fresh file, a fresh email, a fresh attachment, and (probably) a different person opening the wrong one. Tools like Google Slides solve this with a single canonical URL — but only inside their ecosystem, and only if you’re willing to log in.

​
The Slideless loop

Slideless gives you a single URL per deck — and lets you update what’s behind it without ever changing the URL: 
1. AI generates the HTML       (e.g. Claude with `generate-presentation`)
2. You publish it              (one curl, or `share-presentation` skill)
   → returns shareUrl
3. You share the URL           (Slack, email, anywhere)
4. You iterate on the content  (Claude regenerates, you tweak)
5. You re-publish              (one curl with the same shareId)
   → same shareUrl, version + 1, view count preserved
6. Recipients refresh           (they see the new content, no re-share)
That’s it. The URL you sent on Tuesday morning still works on Friday afternoon, even though the content has been edited five times in between.

​
In a terminal

Generate, share, and update — three commands: 
# Generate (with the Claude marketplace skill)
$ claude --skill generate-presentation "Q4 results — revenue, churn, headcount" > deck.html

# Publish
$ curl -X POST https://europe-west1-slideless-ai.cloudfunctions.net/uploadSharedPresentation \
    -H "X-Process-Manager-Key: cko_..." \
    -H "Content-Type: application/json" \
    -d "{\"title\":\"Q4 review\",\"html\":$(cat deck.html | jq -Rs .)}"
# → { "shareUrl": "https://app.slideless.ai/share/abc123?token=..." }

# Iterate, then re-publish (same shareId — URL doesn't change)
$ curl -X POST https://europe-west1-slideless-ai.cloudfunctions.net/updateSharedPresentation \
    -H "X-Process-Manager-Key: cko_..." \
    -H "Content-Type: application/json" \
    -d "{\"shareId\":\"abc123\",\"html\":$(cat deck-v2.html | jq -Rs .)}"
# → { "version": 2, "shareUrl": "https://app.slideless.ai/share/abc123?token=..." }
Hook this into a CI pipeline, a Makefile, a cron job, or a Claude session. The same loop applies.

​
What stays stable across updates

When you re-publish:
Stays the sameBumps / accumulates
shareId (and therefore the share URL)version (auto-increments)
tokens (every share token still works)updatedAt
totalViews (no reset)The HTML content itself
lastViewedAt history
Recipients reload to see the new content. View counts on the deck and on each individual token continue from where they left off.

​
Why this matters

The loop turns a deck from a document (a static artifact you send) into a URL (a living resource you maintain). That’s the same shift the web made for everything else; Slideless brings it to presentations. A few practical applications:
  • Sales decks that get personalized per-prospect (different tokens per recipient, different content updates).
  • Product changelogs that always live at the same URL — every release just re-publishes.
  • Pitch decks you tweak after each investor meeting, without recirculating.
  • Workshop materials that update mid-session as questions come up.

​
Next