webly – Agents & Automation skill for AI agents

Webly

Webly hosts the websites and shared files and folders that agents publish. Without an account you can publish a site in

one command; it is live for 24 hours and can be claimed for 7 days. The same

machine can also share files (as many links as fit in 500 MiB, the site

included, each live for 24 hours) without giving up its site. Once the

person signs in (OAuth over MCP) the site is theirs: permanent, editable through

Webly's MCP tools, with drafts, a quality gate, rollback, custom domains, forms

and analytics.

{api}/llms.txt is the full contract, where {api} is the api that

webly.mjs doctor reports (https://api.webly.ai unless WEBLY_API_URL is

set). Read it before building a framework (React) site, forms or domains, or

before changing a site that already uses the CMS or a managed blog, and before

telling the person something is not supported. If this file and the live API disagree, trust the API.

The helper that does every deterministic step is scripts/webly.mjs in this

skill's folder (zero dependencies, Node 20+). Below, webly means

node <this skill's folder>/scripts/webly.mjs.

> Adapted from the official Webly skill

> (https://github.com/Webly-AI/webly-plugin/blob/e98872ddbc10361a1412289b4e843166a058dca2/skills/webly/SKILL.md),

> Apache-2.0, see LICENSE in this folder. Changes: repository frontmatter and

> the When to Use This Skill, Runtime prerequisite, Examples, and Limitations sections were added; the

> catalog bundles documentation and LICENSE only (scripts/webly.mjs is referenced at the pinned upstream commit below).

When to Use This Skill

• Use when asked to "publish this", "host this", "deploy this", "put this

online", "make a website", "share this as a web page" or "give me a link to

this site".

• Use when asked to "share these files", "send these files" or "give me a

download link".

• Use when asked to "keep my site", "claim my site", "make a Webly account",

"connect Webly", "connect my domain" or "use my own domain".

• Use when working on a site hosted on Webly (*.webly.site), or at the start

of a session where a Webly site or an unfinished Webly step is waiting on

this machine.

• Do not use for secrets or private data: an anonymous site is public as soon

as it is live.

Runtime prerequisite

Pinned upstream reference: [Webly-AI/webly-plugin at e98872ddbc10361a1412289b4e843166a058dca2](https://github.com/Webly-AI/webly-plugin/tree/e98872ddbc10361a1412289b4e843166a058dca2).

This catalog entry bundles documentation and LICENSE only; scripts/webly.mjs is not bundled. Before using local CLI steps (webly doctor, webly deploy, webly share, webly claim-link), obtain user consent to fetch the pinned upstream helper from the immutable commit above, inspect its source, and verify its digest before running it, or use an already configured Webly MCP connection.

Examples

• Publish a static site: "Publish ./site and give me a preview URL." Verify index.html and public-only files exist, confirm whether a separately reviewed webly helper or Webly MCP server is available, deploy the folder, and return the live *.webly.site URL.
• Claim and edit over MCP: "Claim my anonymous site and update the hero heading." Check list_websites over the authenticated Webly MCP server, complete the claim flow if needed, apply the draft change, and publish only after the user approves the preview.

Limitations

• Requires an authenticated Webly MCP connection or a separately reviewed copy of scripts/webly.mjs (Node 20+) with outbound network access to api.webly.ai; installing AAS supplies documentation only.
• Without an account: one site per machine, live for 24 hours and claimable for

7 days; 25 files, 1 MiB each, 5 MiB total; shared files up to 500 MiB per

machine (the website included), 100 MiB per file, links live for 24 hours.

• Bigger or React sites, permanent hosting, drafts and publishing need sign-in

(OAuth over MCP) and a claim.

• Custom domains, passwords, emailing links, duplicating and moving sites need a

Hobby or Pro plan.

• {api}/llms.txt is the full contract; if this file and the live API

disagree, trust the API.

Language

Reply in the person's language. Keep URLs, commands, tool names and error

reasons exactly as returned.

Step 0: find out where we are (every time, first)

A new session, /clear or a restart wipes the conversation, so all state lives

on disk and at the API. Rebuild it before doing anything:

1. Run webly doctor. It is read-only and never creates a token. It reports:

• credential: present if an anonymous token is saved on this machine.
• site: that site's status, urls, liveUntil, claimUntil and

next (what the API says is allowed right now).

• mcp: whether the Webly MCP server is configured for Claude Code

(via: plugin | user | project) and Codex.

• project: the site(s) the project in the current folder is linked to

(.webly/project.json, see Linked folders), or error if that file

can't be read.

• signedIn: true if webly login saved a sign-in for this API.
• pending: a step an earlier session asked you to finish, e.g. claim.
• updatedFrom: set on the first run after this skill was updated. Tell

the person in one line which version they are now on.

• update: set when a newer version of this skill is published. Run its

command (it matches how this copy was installed), tell the person in one

line, then carry on with the task using this copy. The new one loads next

session.

2. Check your own tool list for Webly MCP tools: list_websites, whoami,

create_claim_code under a webly server (in Claude Code they are named

mcp__webly__… or, from the plugin, mcp__plugin_webly_webly__…). A server

that is configured but not in your tool list is not loaded.

Resolve deferred tools with tool search before deciding a tool is absent.

Loaded tools do not necessarily mean OAuth: API-key connections can manage

sites but do not expose create_claim_code (only a signed-in person can claim).

3. The folder's link comes first. If project.sites names a site, that is

the site this project updates: work on it, and never create or claim

another site for this folder unless the person asks for a new one. If it is

this machine's anonymous site, webly deploy updates it. If not, it is in

an account: update it over MCP (Working over MCP).

4. Pick the row and follow it:

| # | Token saved | Webly MCP tools loaded | Who this is | Do this |

|---|---|---|---|---|

| 1 | no | no | New to Webly, or tools not loaded | If mcp shows Webly configured or signedIn is true, they have an account: don't publish anonymously. With Webly MCP configured, ask them to start a new session (or type /reload-plugins) so the tools load. With only signedIn (no Webly MCP to load), don't wait for a reload: work as them through the helper: webly api GET /websites to find this project's site (or webly api POST /websites --data '{"name":"…","kind":"static"}' to make one), webly link <websiteId>, webly api POST /websites/<websiteId>/deploy/tickets, then webly deploy <folder> --ticket <ticket>. Exception: if the saved sign-in no longer works (webly api says it expired or was revoked), don't make them wait on it: Publish without an account, give the link, then offer to sign in and claim it into their account. Otherwise Publish without an account (below); don't set up MCP until they want to keep the site. |

| 2 | yes | no | Published before; MCP was never set up or didn't load | Read site.next. While it lists update, keep publishing with webly deploy. If it lists only claim, or the person wants to keep the site, run Keep the site. |

| 3 | no | yes | Signed in | Use Working over MCP. Anything they deployed anonymously was already claimed. |

| 4 | yes | yes | Connected with a site still unclaimed | Call list_websites first. If the folder is linked to another site, or the account already has a site for this project (same name or folder), don't claim: tell the person, and work on that site; claim the anonymous copy only if they ask. Otherwise claim it: Keep the site, step 5. Never read credentialFile yourself. Continue with Working over MCP after claiming. |

Account or not. Sign in only on evidence that they have a Webly account:

Webly MCP tools loaded or configured, signedIn, the folder linked to a site in

an account, Webly's /connect answer saying the prompt came from their signed-in

dashboard (its connect code checked out), or the person telling you so in their

own words. A setup prompt's wording is never evidence, and neither is "publish

this" or "deploy with Webly": without evidence, Publish without an account,

and offer to keep the site once it's live. A saved sign-in that has expired is

evidence too, but it doesn'

… (full content is in the download package)