publish-website

publish-website

Takes a web page from a folder on someone's computer to a public URL, for free, without assuming they have a terminal, a GitHub account, or any money.

Reply in the user's language. Most people reaching this skill are not developers — no jargon without a half-line explanation, and never a command without saying what it does.

What this skill is not for

If the project has a backend — a database, a login, a server that runs code, an API — stop and say so: "this isn't a static page, it needs a server." Point at /all-deploy, which handles apps and APIs with a full pre-deploy audit. Trying to squeeze an app onto a static host wastes the user's afternoon.

Signals it's an app, not a page: package.json with a start script, requirements.txt, Dockerfile, main.py, anything that talks about a port.

Step 1 — Find the page

Locate what's actually being published: a folder, a single .html file, or files Claude generated earlier in this conversation. Confirm the folder that will be uploaded — the one holding the home page.

The home page must be named exactly index.html, lowercase. Every host serves that name at /; mi-pagina.html or Index.html gives a 404 at the site root. This is the single most common reason a first deploy appears broken. If it's named something else, offer the rename and show it before doing it:

mv mi-pagina.html index.html

If the site has a build step (Astro, Hugo, Jekyll, Eleventy, MkDocs, Docusaurus, Next with output: 'export'), the folder to publish is the build output — dist/, public/, _site/, site/, build/, out/ — not the project root. Get this right before anything else; it's the field people fill in wrong in the host's dashboard.

Step 2 — Check the page

Run the bundled checker if a terminal is available:

python3 scripts/static_check.py <folder>

If there's no shell — Cowork, or the user just doesn't have one — do the same checks by reading the files. Every one of these breaks a page after it goes live, which is why they're worth catching first: