Publishing the artifact you just built.

What you get

// the end-state, before we build it

By the end of this guide, your setup will do four things:

1. A real URL. Every artifact lives at share.yourdomain.com/<slug>. No expiring tokens. No sandbox links.
2. Visitor analytics. Cloudflare Web Analytics, free, privacy-respecting. You see who looked at the proposal you sent on Tuesday.
3. Lock when it matters. Sensitive client work goes behind Cloudflare Access — a one-time email PIN before the page renders. Public stuff stays public.
4. Claude does the publishing. When you say "publish this," Claude knows the slug rules, injects the analytics snippet, runs the deploy, and hands you the URL.

Cost: $0 if you already own a domain on Cloudflare. Workers' free tier is 100k requests/day. Web Analytics is free. Cloudflare Access is free up to 50 users. You will not spend money to do this.

Prereqs

// boring but unavoidable

• Node + npm installed (any recent version). Wrangler runs through npx.
• A Cloudflare account. Free tier is fine.
• A domain you control. You can use Cloudflare Registrar or move DNS from wherever you bought it.
• Claude Code installed locally (this is where the skill lives).

Get a domain into Cloudflare

// skip this if your domain is already on Cloudflare

Two paths:

1. Buy fresh. Cloudflare Registrar. It's the cheapest of the major registrars and your DNS is automatically managed. Done in 5 minutes.
2. Move DNS only. Keep your domain registered wherever it is. In the Cloudflare dashboard, click + Add site, paste your domain, follow the nameserver instructions. Propagation takes 5 minutes to a few hours.

Once your domain shows up under Websites in the dashboard with a green Active status, you're done with this step.

Create the share Worker

// one folder, two files, one command

Wrangler is Cloudflare's deploy CLI. A Worker with the new assets config is the simplest way to serve a static site — no Workers Sites, no Pages config, just here's a folder, serve it.

— Step 1. Create the folder structure:

bash# Create a directory anywhere — examples below assume ~/share/
mkdir -p ~/share/deploy
cd ~/share

— Step 2. Save this as wrangler.jsonc:

wrangler.jsonc{
  "name": "share-worker",
  "compatibility_date": "2024-09-23",
  "assets": {
    "directory": "./deploy",
    "not_found_handling": "404-page"
  }
}

— Step 3. Drop a placeholder deploy/index.html so the first deploy has something to serve. Anything works — an <h1>ok</h1> is fine.

— Step 4. Authenticate Wrangler with Cloudflare (one-time, opens a browser):

bashnpx wrangler login

— Step 5. Deploy:

bashnpx wrangler deploy

Wrangler prints a *.workers.dev URL. Visit it. You should see your placeholder. That's it — you have a publishing surface.

Wire your domain to the Worker

// share.yourdomain.com instead of share-worker.username.workers.dev

1. Cloudflare dashboard → Workers & Pages → click share-worker.
2. Settings → Domains & Routes → Add → Custom Domain.
3. Type share.yourdomain.com. Cloudflare creates the DNS record and provisions a cert automatically. Wait 30-60 seconds.
4. Visit https://share.yourdomain.com/. Same placeholder you saw on the *.workers.dev URL. Real domain. Real cert. Real URL.

From now on, anything you put in deploy/<slug>/index.html is reachable at share.yourdomain.com/<slug> after a deploy. That's the whole pattern.

Install the Claude Code skill

// teach Claude the loop, once, then never think about it again

The skill is a single Markdown file. Drop it in ~/.claude/skills/publish-artifact/SKILL.md and Claude Code will trigger it any time you say "publish this", "give me a URL for this", or "update the published version".

On first run the skill asks for two things — where your share directory lives and what your share domain is — and writes them to ~/.config/publish-artifact/config.json. Nothing about your machine is baked in.

Copy the contents below into ~/.claude/skills/publish-artifact/SKILL.md:

SKILL.md---
name: publish-artifact
description: Publish any HTML artifact to share.yourdomain.com with a clean URL,
  visitor analytics, and optional password protection. Triggers on "publish this",
  "make this shareable", "ship to share", "deploy this artifact", "give me a URL
  for this", or "update the published version".
---

# Publish HTML Artifact

## Configuration

Read config from ~/.config/publish-artifact/config.json:

  {
    "share_dir": "~/share",
    "share_domain": "share.yourdomain.com",
    "cf_beacon_token_path": "~/.config/publish-artifact/cf-beacon-token",
    "protected_path_prefix": "/c/"
  }

If missing, ask the user for share_dir and share_domain on first run, then
write the config. Expand ~ to the home directory before using.

## Pre-flight

1. Confirm the artifact is a single self-contained HTML file. If it has
   relative <img>, <link>, or <script> references, inline them or move
   the assets into the same slug folder.
2. Ensure the Cloudflare Web Analytics beacon is in <head>. Read the token
   from cf_beacon_token_path and substitute. Inject if missing.
3. If the user calls it "client work," "sensitive," or names a recipient,
   ASK whether to put it behind Cloudflare Access before deploying.

## Publish flow

1. Determine a slug (kebab-case, ~40 chars max). Confirm if ambiguous.
2. Write the artifact to: <share_dir>/deploy/<slug>/index.html
3. Run from <share_dir>: npx wrangler deploy
4. Report the live URL: https://<share_domain>/<slug>

## Update

For "redeploy" or "update the published version": overwrite the existing
<share_dir>/deploy/<slug>/index.html, preserve the analytics beacon,
deploy.

## Protected publish

For sensitive content, deploy under <protected_path_prefix><slug>/
(e.g. /c/<slug>/). Confirm with the user that a Cloudflare Access
policy already covers <protected_path_prefix>* before claiming the
path is protected.

## What not to do

- Don't hardcode paths. Always read from the config file.
- Don't deploy with unresolved relative refs — fail loud.
- Don't claim a path is protected unless the user confirmed an Access policy.
- Don't deploy artifacts containing secrets, API tokens, or PII —
  strip or refuse.

The skill auto-loads next time you open Claude Code. Test it: open a session, ask Claude to build a simple HTML page, then say "publish this as my-test". Watch it run the loop end-to-end.

Publish your first artifact

// the moment it all becomes worth it

The whole loop, once everything above is in place:

claude code# You, in any Claude Code session, after Claude has built an HTML artifact:

You: publish this as q2-proposal

Claude: ✓ Wrote ~/share/deploy/q2-proposal/index.html (47 KB)
        ✓ Injected Cloudflare Web Analytics beacon
        ✓ Ran wrangler deploy

Live at: https://share.yourdomain.com/q2-proposal

That's it. The URL is real, the page is live, the cert is valid. You can email it, link it from Notion, paste it in a Slack DM. The artifact escaped the sandbox.

Add visitor analytics

// know if your prospect actually opened the proposal

1. Cloudflare dashboard → Analytics & Logs → Web Analytics.
2. Click Add a site. Choose Add a JS snippet to my site.
3. Cloudflare gives you a beacon token. Copy it.
4. Drop the snippet into the <head> of every published artifact:

html<!-- Cloudflare Web Analytics -->
<script defer
  src="https://static.cloudflareinsights.com/beacon.min.js"
  data-cf-beacon='{"token": "YOUR_BEACON_TOKEN_HERE"}'></script>

The skill above already injects this on every publish — once you store your token at ~/.config/publish-artifact/cf-beacon-token (or wherever cf_beacon_token_path in your config points), Claude reads it and substitutes. You'll see pageviews, referrers, and country breakdowns in the Cloudflare dashboard within minutes of the first visit.

Privacy: Cloudflare Web Analytics doesn't use cookies, doesn't fingerprint, and is GDPR/CCPA friendly out of the box. You're not adding tracking debt.

Lock down sensitive paths

// for the client work that should never have been on a public URL

Cloudflare Access (part of Zero Trust) puts an authentication gate in front of any path you choose. The lightest option: one-time email PIN. Recipient enters their email, gets a 6-digit code, enters it, sees the page. No accounts to create. No passwords to manage.

1. Cloudflare dashboard → Zero Trust. First time, you'll set up a team name (free).
2. Access → Applications → Add an application → Self-hosted.
3. Application domain: share.yourdomain.com with path /c/* (convention: put all client work under /c/<client>/<slug>).
4. Add a policy → Allow → set Include to Emails, list the addresses that should have access.
5. Identity provider: enable One-time PIN (no SSO setup required).

From now on, anything you publish under share.yourdomain.com/c/... is gated. Public stuff stays public. The skill knows to ask before deploying to a protected path if you call something "sensitive" or "client work."

Caveat: Cloudflare Access protects access, not extraction. If a recipient who has access takes a screenshot, the screenshot exists. Use it for "don't let the wrong eyes find this URL," not for DRM-grade containment.

What I'd build next

// not in this guide, but worth your weekend

• Auto-expiry. A Worker route that 410s URLs older than N days unless flagged permanent. Stops link-rot.
• Per-recipient tokens. Bake a per-visitor token into the URL so analytics shows which specific person opened the proposal, not just "someone in Calgary."
• Bring-your-own subdomain per client. acme.share.yourdomain.com is one DNS record away from being a thing. Makes the deliverable feel bespoke.

If you build any of these, I'd love to see them. Tag me on LinkedIn, or just publish your version to your share subdomain and send me the URL. That would be a fitting way to close the loop.