Nothing happened when you asked Claude to publish. There are four separate things it could mean, they look identical from the chat window, and each has a different fix. Here's how to tell them apart in order.
You asked Claude to publish the page it just built. Nothing came back — or something came back that isn't a link, or a link that opens onto half a page. The chat window gives you one undifferentiated symptom for four unrelated problems.
Almost every "the Skill doesn't work" report is the same thing: only half the setup happened.
A Skill is a file of instructions. It tells the model what a capability is for, when to offer it, and how to behave around its edges — publish after building a page, keep the same link when revising, hand off to a direct upload when the file is large. What a Skill cannot do is give the model a new ability. It describes one.
A connector is the ability. It's what actually puts a document somewhere and hands back a URL. It's attached once, in your AI client's settings, and it's a different piece of setup from dropping in a Skill file.
Install the Skill alone and you get a model that has read a detailed briefing about a tool it does not possess. That's why the symptom is so slippery — it isn't a crash, it's a model reasoning as helpfully as it can about equipment that isn't in the room. Install the connector alone and everything works; you just have to ask for it explicitly each time.
So the first question is never "is my Skill broken". It's does the tool exist.
Ask, in plain words: what tools do you have available for publishing? You're looking for the tool by name in the answer, not for reassurance.
If it isn't there, the connector isn't attached, and nothing further down this page applies. Attach it in your client's settings and retry. Worth knowing before you start: on a managed work machine this can be an administrator setting rather than a personal one, and no amount of rephrasing gets around it — that's the point at which the browser uploader becomes the shorter path, not the fallback.
A connector can be attached and unauthenticated. It's the least intuitive state because everything looks installed.
The signature is that you get a sign-in prompt, or a message about not being signed in — a response about your identity, not about your document. Complete the sign-in once and repeat the same request. If the second attempt behaves identically, you're back at layer 1: something isn't attaching, rather than something not authenticating.
The useful mental split: layers 1 and 2 are about whether the tool can be reached. Only from layer 3 does your file matter at all.
This is the layer people misread most often, because a refusal feels like a failure. It isn't. A refusal means the whole chain worked: the model reached for the tool, the tool reached the service, the service looked at your document and declined for a stated reason.
Read the sentence literally. The reasons are specific and they are all actionable:
Every one of these is a completed round trip. If you're seeing one, stop looking for a broken install.
This is the layer worth understanding properly, because the two ways it breaks look nothing alike and neither produces the message you'd expect.
When you publish through a chat tool, the HTML travels as a text argument the model writes out. It is not a file transfer. The document is, in a real sense, retyped into the tool call.
Between roughly 100 KB and a few megabytes: silent truncation. The receiving end is perfectly happy at these sizes — a 322 KB page and a 3.1 MB page both published without complaint when sent as raw bytes. What can't keep up is the model's own output budget. The document gets cut short on the way out, and because nothing was rejected, nothing complains. You get a link. The link opens. The page stops halfway, or renders blank because the closing half of a script never arrived.
Past a few megabytes: a bare 413. Now the request doesn't survive the trip at all. It's refused in transit by the infrastructure in front of the application — measured today, a 3.1 MB document went through and a 4.6 MB one came back as {"error": {"code": "413", "message": "Request Entity Too Large"}}. Note what you don't get: no mention of your plan, no mention of a cap, no advice. The friendly "this page exceeds your plan's limit" wording lives in the application, and at this size the application never saw your request. A raw 413 is not a plan problem and no upgrade fixes it — it's a statement about the pipe, not the destination.
The trap in both cases is that every instinct is wrong. Retrying reproduces it. Rephrasing the prompt reproduces it. Splitting the file across two calls produces two broken halves. It isn't a limit of where the file is going — a direct upload of the same page is unremarkable — it's a limit of the route it took.
The fix is to stop routing the document through the conversation: upload the file itself, in a browser or from the command line, where actual bytes are sent. This is also why a well-written Skill tells the model to refuse the chat route for large files rather than attempt it — a refusal you can read beats a truncation you can't see. If you're building something big enough to hit this, the export checklist for a self-contained page is worth a pass first; a page that inlines every asset is easier to hand over but noticeably heavier, and sending it as a zip versus a hosted link changes which ceiling you meet.
None of these four checks is clever. What does the work is running them in sequence, because each one makes the next meaningful:
Debugging out of order is what turns fifteen minutes into an afternoon — people rewrite prompts to fix an unattached connector, or upgrade a plan to fix a truncation that no plan affects.
And it's worth separating this class of problem from its neighbour. Everything above is about the link failing to get made. A link that gets made and then won't open for the person you sent it to is a different question with different causes — that one is usually about who the link was designed for, not about how it was published.
If you want the setup without the diagnosis: the connector is the part that has to work, and the Skill is the part that makes Claude offer the link without being asked.
AI builders ship beautiful forms with no idea where the submissions go. Three shapes that actually work — mailto, third-party embed, serverless route — and the prompts that make each one ship cleanly.
AI builders default to heavy: full framework bundles, web fonts, icon libraries, generous markup. Prompts that ship lean from the start, plus the trim pass for what slipped through.
AI tools default to modular HTML — clean for development, fragile for one-file delivery. Cross-tool prompt templates that produce a single portable file from the first generation.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.