How I publish an AI-generated HTML presentation without building a hosting pipeline

Coding agents are surprisingly good at producing a polished HTML presentation. The awkward part
starts one minute later: how do you turn that local artifact into a URL without asking the agent to
invent a deployment pipeline, leak a credential, or silently publish the wrong file?

I’m building Slidesfly, so this is not a neutral survey of every hosting option. It is the workflow
I now use when Codex, Claude Code, Cursor, or another coding agent has already produced a
browser-ready deck. The important part is not the product command. It is the handoff contract and
the verification around it.

Treat publishing as a separate stage

The agent that creates a deck usually works in a repository containing source files, generated
assets, build output, screenshots, and temporary experiments. “Publish my slides” is therefore an
ambiguous instruction. An agent can easily choose src/index.html instead of dist/index.html, or
upload an HTML shell whose JavaScript only works on localhost.

I use a four-stage boundary:

1. Generate the presentation.
2. Verify the exact browser-ready artifact locally.
3. Publish that exact path through a dedicated interface.
4. Open the returned reader URL before sharing it.

This boundary keeps content generation and deployment independent. A publishing failure does not
invite the agent to rewrite the deck, and a deck bug does not get hidden by a successful upload.

Start with an exact artifact

For a single-file deck, open the file locally and check navigation, fonts, images, and the browser
console. For a framework build, identify the actual output directory and whether it depends on an
absolute base path or remote assets.

Then give the agent an absolute path rather than a guessed filename:

Publish /absolute/path/deck.html with Slidesfly. Return the complete reader URL,
verify it opens, and keep claim tokens or API keys out of the response.

That prompt is deliberately boring. It names one artifact, defines the expected result, asks for an
effect check, and establishes a credential boundary.

Install the publishing interface

The supported website installer provides the CLI and can install the Slidesfly instruction file for
several agent hosts:

curl -fsSL https://slidesfly.com/install.sh | sh
slidesfly --version

# Pick the host you actually use
slidesfly install --target codex --scope user --json
slidesfly install --target claude-code --scope user --json
slidesfly install --target cursor --scope user --json

The instruction file does not contain a new credential. It teaches the agent when to use the local
CLI or a configured MCP connection, what result to return, and when to stop.

Publish the verified file with structured output:

slidesfly publish /absolute/path/deck.html \
  --title "Agent-generated review" \
  --json

A successful response includes ok: true, a deck id, a complete reader URL, visibility, and whether
the publish is anonymous. The command's normal and JSON output omit the anonymous claim token.

The first single-file publish can be anonymous. That is useful for an agent workflow because the
artifact can become a URL before an account flow interrupts the task. The local CLI stores the claim
token in its config so the deck can be claimed later. The token should never be copied into chat,
logs, or source control.

Verify the result, not the command

An HTTP upload succeeding only proves that bytes reached a service. It does not prove the deck
works in its final reader.

Open the returned URL and check at least:

• the first slide renders;
• next/previous navigation works;
• local fonts, images, styles, and scripts load;
• there is no dependency on localhost or a private file path;
• the result does not require same-origin storage or top-level navigation.

Slidesfly renders uploaded HTML in a sandboxed, opaque-origin iframe. That boundary is intentional,
but it can expose assumptions that were invisible during local development. If the deck requires a
remote runtime script, same-origin cookies, or application-hosting behavior, report the reader as
unverified and fix the artifact. Do not weaken the verification language just because publishing
succeeded.

A reproducible proof

I keep a small example artifact so the full chain can be inspected instead of merely asserted:

• source HTML
• live reader
• canonical workflow and current verification record

At the recorded verification point, the 1,953-byte source and the reader asset had the same SHA-256:

54d0fe40d1e1ea36b2a5150c8ec4eb4603a32cc59847e16deb5c855c5b1f9965

That hash proves only the linked fixture at that recorded point. It is not evidence that every
uploaded presentation is byte-identical or visually correct. Each new artifact still needs its own
verification.

Recovery should be explicit

Agent workflows become much safer when failures have a narrow next step:

• File not found: locate the real build output, inspect it, and retry with the exact path.
• Invalid file or HTML: choose the actual .html, .htm, or eligible ZIP artifact; do not rename an unrelated file to bypass validation.
• Security rejection: fix the source and rerun local verification. Never conceal or automatically bypass the rejection.
• Authentication required: use the agent host's approved secret mechanism. Do not paste an API key into the conversation.
• Reader verification fails: report an unverified result, identify the sandbox or asset assumption, repair the artifact, republish, and reopen the URL.

Notice what is absent: “try random deployment changes until something is online.” Publishing is a
small, auditable stage with a defined input and output.

When this workflow is the wrong tool

Slidesfly publishes existing HTML presentations. It is not an AI presentation generator and it is
not a general application host. Use a normal web deployment platform if the output is an
application with a backend, same-origin authentication, unrestricted navigation, or server-side
runtime requirements.

For a finished HTML deck, though, separating generation from publishing gives the agent a much
cleaner job: identify one verified artifact, publish it, open the returned URL, and report the result
without exposing credentials. That is the whole pipeline—and that simplicity is the feature.