shiply-cli 0.27.2 → 0.28.0

package/dist/access.js

@@ -0,0 +1,54 @@
+import { api, resolveBase } from './publish.js';
+const headers = (apiKey) => ({
+    'content-type': 'application/json',
+    authorization: `Bearer ${apiKey}`,
+});
+/** Stable machine marker (mirrors SITE_READY / VERIFY) so agents can parse the
+ *  policy without scraping the human lines. Counts, not values — emails can
+ *  contain characters that would break k=v tokenizing. */
+function marker(slug, p) {
+    return `ACCESS slug=${slug} mode=${p.mode} password=${p.hasPassword ? 'set' : 'none'} emails=${p.allowedEmails.length} domains=${p.allowedDomains.length}`;
+}
+function printPolicy(slug, p) {
+    if (p.mode === 'public') {
+        console.log(`  ${slug} is public — anyone with the URL can view it`);
+    }
+    else if (p.mode === 'password') {
+        console.log(`  ${slug} is password-protected${p.hasPassword ? '' : ' (no password set yet — visitors are locked out)'}`);
+    }
+    else {
+        console.log(`  ${slug} is invite-only (restricted)`);
+        for (const e of p.allowedEmails)
+            console.log(`    email:  ${e}`);
+        for (const d of p.allowedDomains)
+            console.log(`    domain: @${d.replace(/^@/, '')}`);
+        if (p.allowedEmails.length === 0 && p.allowedDomains.length === 0) {
+            console.log('    (no emails or domains allowed — only the owner can view)');
+        }
+    }
+    console.log(marker(slug, p));
+}
+export async function accessShow(ctx, slug) {
+    const base = resolveBase(ctx.base);
+    const p = await api(`${base}/api/v1/publishes/${encodeURIComponent(slug)}/access`, {
+        headers: headers(ctx.apiKey),
+    });
+    printPolicy(slug, p);
+}
+export async function accessSet(ctx, slug, input) {
+    const base = resolveBase(ctx.base);
+    const body = { mode: input.mode };
+    if (input.mode === 'password')
+        body.password = input.password;
+    if (input.mode === 'restricted') {
+        body.allowedEmails = input.allowedEmails ?? [];
+        body.allowedDomains = input.allowedDomains ?? [];
+    }
+    const p = await api(`${base}/api/v1/publishes/${encodeURIComponent(slug)}/access`, {
+        method: 'PATCH',
+        headers: headers(ctx.apiKey),
+        body: JSON.stringify(body),
+    });
+    console.log(`✔ access updated — existing visitor cookies are now invalid`);
+    printPolicy(slug, p);
+}

package/dist/index.js

@@ -33,6 +33,7 @@ import { readState, writeState } from './state.js';
 import { readPreview, writePreview } from './previews.js';
 import { checkReadiness, targetToHostname } from './status.js';
 import { runStatus } from './status-cmd.js';
+import { accessSet, accessShow } from './access.js';
 import { sitesLs, sitesPromote, sitesRm, sitesRollback } from './sites.js';
 import { verifySite } from './verify.js';
 // Resolve the package.json beside the compiled dist/ so `shiply --version`
@@ -75,6 +76,12 @@ Usage:
   shiply db branches <db>                      List branches of a Neon database
   shiply db delete-branch <branch-or-id> --yes Delete a Neon branch
   shiply db merge <branch>                     No-op alias — prints the pg_dump migration tip
+  shiply access <slug>                        Show who can view the site (public/password/restricted)
+  shiply access <slug> --public               Open the site to everyone
+  shiply access <slug> --password <pw>        Password-protect the site (paid plan)
+  shiply access <slug> --restricted --email a@b.com --domain example.com
+                                              Invite-only: only listed emails / email domains
+                                              (--email/--domain repeatable; replaces the previous lists)
   shiply domain ls                            List custom domains on your account
   shiply domain add <domain>                  Register a custom domain
   shiply domain connect <domain>              One-click OAuth DNS setup (Cloudflare/Domain Connect)
@@ -231,7 +238,13 @@ async function main() {
             key: { type: 'string' },
             anonymous: { type: 'boolean' },
             base: { type: 'string' },
-            email: { type: 'string' },
+            // `--email` is repeatable for `access --restricted`; `login --email` uses
+            // the last value. `--domain` is the access counterpart for whole domains.
+            email: { type: 'string', multiple: true },
+            domain: { type: 'string', multiple: true },
+            public: { type: 'boolean' },
+            password: { type: 'string' },
+            restricted: { type: 'boolean' },
             name: { type: 'string' },
             as: { type: 'string' },
             wait: { type: 'boolean' },
@@ -617,6 +630,47 @@ async function main() {
             process.exitCode = ready ? 0 : 1;
             return;
         }
+        case 'access': {
+            const usage = 'usage: shiply access <slug> [--public | --password <pw> | --restricted --email a@b.com --domain example.com]';
+            if (!dir)
+                throw new Error(usage);
+            const apiKey = values.key ?? (await loadApiKey());
+            if (!apiKey)
+                throw new Error('access needs an API key — run `shiply login` first');
+            const actx = { base: values.base, apiKey };
+            const modes = [
+                values.public ? 'public' : null,
+                values.password !== undefined ? 'password' : null,
+                values.restricted ? 'restricted' : null,
+            ].filter(Boolean);
+            if (modes.length === 0) {
+                // No mode flag → read-only: print the current policy.
+                await accessShow(actx, dir);
+                return;
+            }
+            if (modes.length > 1)
+                throw new Error(`pick ONE mode — ${usage}`);
+            const mode = modes[0];
+            // --email/--domain are repeatable and accept comma-separated lists.
+            const split = (vals) => (vals ?? []).flatMap((v) => v.split(',')).map((s) => s.trim()).filter(Boolean);
+            const allowedEmails = split(values.email);
+            const allowedDomains = split(values.domain);
+            if (mode === 'password' && !values.password?.trim()) {
+                throw new Error('--password needs a value, e.g. shiply access <slug> --password "s3cret-phrase"');
+            }
+            if (mode !== 'restricted' && (allowedEmails.length > 0 || allowedDomains.length > 0)) {
+                throw new Error('--email/--domain only apply with --restricted');
+            }
+            if (mode === 'restricted' && allowedEmails.length === 0 && allowedDomains.length === 0) {
+                throw new Error('--restricted needs at least one --email or --domain (otherwise only you could view the site)');
+            }
+            await accessSet(actx, dir, {
+                mode,
+                ...(mode === 'password' ? { password: values.password.trim() } : {}),
+                ...(mode === 'restricted' ? { allowedEmails, allowedDomains } : {}),
+            });
+            return;
+        }
         case 'promote': {
             const dest = values.to;
             if (!dir || !dest)
@@ -1082,7 +1136,7 @@ async function main() {
             // Default path: device flow. One click in the browser, no email round-trip.
             // The --email flag opts into the legacy code-by-email path (useful for
             // scripted/non-interactive runs that can't open a browser).
-            if (!values.email) {
+            if (!values.email?.length) {
                 const result = await loginViaDeviceFlow(base, values.name);
                 if (!result.ok) {
                     console.error(`✗ login failed: ${result.reason}`);
@@ -1097,7 +1151,7 @@ async function main() {
             }
             const rl = createInterface({ input: process.stdin, output: process.stdout });
             try {
-                const email = values.email;
+                const email = values.email[values.email.length - 1];
                 await api(`${base}/api/auth/agent/request-code`, {
                     method: 'POST',
                     headers: { 'content-type': 'application/json' },

package/package.json

@@ -1,42 +1,42 @@
-{
-  "name": "shiply-cli",
-  "version": "0.27.2",
-  "description": "Publish static sites to shiply.now from the command line \u00e2\u20ac\u201d instant web hosting for agents.",
-  "license": "MIT",
-  "type": "module",
-  "bin": {
-    "shiply": "dist/index.js"
-  },
-  "files": [
-    "dist",
-    "skill",
-    "README.md"
-  ],
-  "scripts": {
-    "build": "tsc -p tsconfig.build.json",
-    "prepublishOnly": "pnpm build",
-    "test": "vitest run",
-    "typecheck": "tsc --noEmit"
-  },
-  "engines": {
-    "node": ">=18"
-  },
-  "keywords": [
-    "shiply",
-    "hosting",
-    "static",
-    "deploy",
-    "agents",
-    "publish"
-  ],
-  "homepage": "https://shiply.now",
-  "devDependencies": {
-    "@types/node": "^22.15.0",
-    "typescript": "^5.8.0",
-    "vitest": "^3.1.0"
-  },
-  "dependencies": {
-    "esbuild": "^0.25.12",
-    "smol-toml": "^1.7.0"
-  }
-}
+{
+  "name": "shiply-cli",
+  "version": "0.28.0",
+  "description": "Publish static sites to shiply.now from the command line \u00e2\u20ac\u201d instant web hosting for agents.",
+  "license": "MIT",
+  "type": "module",
+  "bin": {
+    "shiply": "dist/index.js"
+  },
+  "files": [
+    "dist",
+    "skill",
+    "README.md"
+  ],
+  "scripts": {
+    "build": "tsc -p tsconfig.build.json",
+    "prepublishOnly": "pnpm build",
+    "test": "vitest run",
+    "typecheck": "tsc --noEmit"
+  },
+  "engines": {
+    "node": ">=18"
+  },
+  "keywords": [
+    "shiply",
+    "hosting",
+    "static",
+    "deploy",
+    "agents",
+    "publish"
+  ],
+  "homepage": "https://shiply.now",
+  "devDependencies": {
+    "@types/node": "^22.15.0",
+    "typescript": "^5.8.0",
+    "vitest": "^3.1.0"
+  },
+  "dependencies": {
+    "esbuild": "^0.25.12",
+    "smol-toml": "^1.7.0"
+  }
+}

package/skill/CHANGELOG.md

@@ -6,6 +6,16 @@ entry here, that capability may be missing from your copy — re-install with
 (This is the agent-facing capability log; the CLI's own release notes live in
 the npm package changelog.)
 
+## 2026-07-14
+
+- **New** — `shiply access <slug>` manages site privacy without raw REST:
+  no flags prints the current policy (with a stable `ACCESS slug=… mode=…`
+  marker line), `--password <pw>` password-protects, `--restricted
+  --email a@b.com --domain example.com` makes it invite-only (flags
+  repeatable; each set replaces the previous lists), `--public` opens it
+  back up. Password/restricted modes need a paid plan. Details in
+  references/site-features.md.
+
 ## 2026-07-08
 
 - **Fix** — re-publishing an unchanged large SSR site (e.g. a 171-file

package/skill/SKILL.md

@@ -1,253 +1,254 @@
----
-name: shiply
-description: "shiply is the production backend for anything an agent builds — publish any app (static or full-stack SSR, any framework) and give it a live URL, custom domain, SQL database, server functions, email, and a marketplace to sell it. Use when the user asks to publish, host, deploy, share, or update a website/page/demo/report/app, or wants a live URL for generated files. Triggers - \"publish this\", \"host this\", \"put this online\", \"give me a link\", \"update the site\", \"deploy my SvelteKit/Astro/Next.js app\", shiply."
----
-
----
-
-> **IMPORTANT — npm package name is `shiply-cli`, NOT `shiply`.** A different
-> npm package named `shiply` (an auto-commit watcher) is published by someone
-> else — installing it does NOT give you the shiply.now CLI. Always use
-> `npx -y shiply-cli@latest …` or `npm install -g shiply-cli`. The CLI binary
-> on PATH is still named `shiply` once installed; the warning is only about
-> the npm package name.
-
-> **Skill freshness check.** Shiply ships new capabilities weekly.
-> **This skill: version 0.27.0, last updated 2026-07-11.**
-> To see what changed since your copy was written, fetch
-> `https://shiply.now/changelog.md` (date-grouped, newest first) — if it lists
-> capabilities newer than the date above, re-install with
-> `npx -y shiply-cli@latest skill --force` OR read the live copy at
-> `https://shiply.now/skill.md`.
-
----
-
-# shiply — the production backend for anything an agent builds
-
-**What it is.** Not static hosting. shiply takes whatever you build — a static page or a full-stack app in any framework — and gives it a live URL, a custom domain, a SQL database, server functions, email (send + receive), and a marketplace to sell it. One call. No account needed to start: anonymous sites are live immediately, last 24 hours, and can be claimed to keep.
-
-**Why use it.** Ship a complete, working product without stitching together a host + database + email + registrar + payments — it's one agent-native platform (MCP / CLI / REST parity). Hard-ceiling pricing ($0/$8/$24, plus a $49 Studio tier for client delivery — no usage meter on any tier), so a spike or DDoS can never become a surprise bill for the owner.
-
-**How (quickstart).** `shiply publish ./dir` (CLI) — or POST /api/v1/publish → PUT each file → POST finalize — returns a live URL + claimToken.
-
-**NEVER create a new site to update an existing one. Always re-publish to the
-same site** (same slug/claimToken) — otherwise you litter subdomains and lose
-the user's URL.
-
-**Re-publishing the same site is cheap — always prefer it over a new site.**
-Unchanged files are hash-skipped, and an unchanged SSR worker bundle skips
-redeploy entirely (fingerprinted against what's already live). A zero-change
-`shiply publish` on the same site completes in seconds, even for large SSR
-apps — so iterate freely by re-publishing, never by spinning up a fresh site.
-
-This file covers the core path: publish → authorize → update → claim → verify.
-Everything else (databases, domains, SSR, email, functions, client work) lives
-in the **topic files indexed at the bottom** — read the one that matches the
-task before improvising.
-
-## First publish on a new machine: ask for a permanent key in one step
-
-On a no-Bearer publish, include `"agentName": "<your-tool-name>"` in the body
-(e.g. `"Claude Code"`, `"Cursor"`). The response will include a `deviceAuth`
-object alongside the usual `claimUrl`:
-
-```
-"deviceAuth": {
-  "user_code": "ABCD-EFGH",
-  "device_code": "<long opaque token, keep private>",
-  "verification_url": "https://shiply.now/auth/ABCD-EFGH",
-  "poll_url": "https://shiply.now/api/v1/auth/device/poll",
-  "expires_in": 900,
-  "interval": 2
-}
-```
-
-Tell the user once, in plain language:
-
-> Your site is live at <siteUrl>. To keep it forever AND let me publish more
-> without re-pasting, open <verification_url> and click Allow.
-
-Then immediately poll `verification_url`'s sibling endpoint until the user
-acts:
-
-```
-POST https://shiply.now/api/v1/auth/device/poll
-{"device_code": "<the device_code from the response>"}
-```
-
-The response is one of `{status:"pending"}` (keep polling at `interval`s),
-`{status:"approved", api_key:"shp_...", slug_claimed:"..."}` (PERSIST the key —
-see "Save the key" below — the site is now permanent; Allow does both jobs in
-one click), `{status:"expired"|"denied"|"consumed"}` (stop). Cap your polling at
-the announced `expires_in` and respect `interval` — don't tight-loop.
-
-After approval, every future publish uses `Authorization: Bearer <api_key>`
-and the user's dashboard shows their sites without any further claiming.
-
-### Save the key — so EVERY future site is seamless (do this once)
-
-Write the key to **`~/.shiply/credentials`** as `{"apiKey":"shp_..."}` (chmod
-600) — the exact file the shiply CLI reads. This is what makes "one Allow, ever"
-work: from then on every publish (any site, any project, ANY FUTURE SESSION)
-sends `Authorization: Bearer <key>` automatically and lands owned in the user's
-dashboard — no re-authorizing, no claim step, zero clicks. An env var alone
-(`SHIPLY_API_KEY`) works for the current shell but does NOT survive a new
-session — the credentials file is what makes it permanent. `shiply login` writes
-this file for you; if you publish over raw HTTP, write it yourself.
-
-## When the user pastes you something shiply-shaped, do this
-
-These are the patterns you will see. Match the input, run the action — do not
-ask the user to repeat themselves or explain.
-
-- **Code like `SHIPLY-XXXXXXXX`** → it's a pairing code from
-  `shiply.now/claim/<slug>?pair=1`. The user wants to attach an anonymous
-  site to their account. Run `shiply claim verify SHIPLY-XXXXXXXX` from the
-  directory you originally published from (it reads `.shiply.json`). No CLI?
-  POST `https://shiply.now/api/v1/claim/pair/SHIPLY-XXXXXXXX/verify` with
-  `{"siteId":"...","claimToken":"..."}` taken from your earlier publish
-  response or `.shiply.json`. The user's browser auto-redirects on success;
-  tell them to switch back to it.
-- **URL like `https://shiply.now/claim/<slug>?token=...`** → one-click claim
-  link. Tell the user to open it in the browser they are signed in to —
-  do NOT call any API yourself.
-- **User says "claim my site" / "save it forever" with no code or URL** →
-  give them the `claimUrl` from your last publish response. If you no longer
-  have that response but `.shiply.json` is in the publish dir, reconstruct it
-  as `https://shiply.now/claim/<slug>?token=<claimToken>` from those fields.
-  Either way, also suggest `shiply login` so future publishes mint to their
-  account directly — that's the long-term fix and how the dashboard works.
-- **User says "I have an API key now, use it from now on"** → persist it to
-  `~/.shiply/credentials` (`{"apiKey":"shp_..."}`, chmod 600 — see "Save the
-  key" above), then send `Authorization: Bearer <key>` on every future publish.
-  All future sites are then permanent and appear in their dashboard
-  automatically — across sessions, with no re-authorizing.
-- **User opens an `https://shiply.now/auth/XXXX-YYYY` URL you printed** → no
-  action from you; they're on the device-flow consent screen. Keep polling
-  `poll_url` (see "First publish on a new machine" above). The poll response
-  will flip from `pending` to `approved` (with `api_key`) the moment they
-  click Allow.
-
-## Pick your interface (best first)
-
-### 1. MCP (native tools)
-If the `shiply` MCP server is connected (https://shiply.now/mcp), use
-`publish_site`. Every result includes a `toUpdate` field telling you the exact
-call for updates — follow it, and a `shareSuggestion` you can relay to the user.
-Core tools: `site_status`, `list_sites`, `get_site`, `delete_site`, `whoami`,
-`duplicate_site`, `set_variable`, `get_analytics`, `set_handle`. There are
-100+ tools in total — call `tools/list` for the authoritative set; the topic
-files below name the tools for their area (domains, databases, email,
-functions, projects, contracts, marketplace, drives).
-
-### 2. CLI
-```bash
-# IMPORTANT: the npm package is `shiply-cli`, not `shiply` (different package).
-npm i -g shiply-cli        # or: npx -y shiply-cli@latest <command>
-                           # or: curl -fsSL https://shiply.now/install.sh | bash
-shiply publish ./dir       # live URL + confetti
-shiply publish ./dir       # run AGAIN after edits → updates the SAME site
-shiply status <slug> --wait  # SSL + readiness; prints SSL_READY / SITE_READY
-shiply login               # email code → API key → sites become permanent
-shiply claim verify <code> # confirm a SHIPLY-XXXXXXXX pairing code from /claim/<slug>?pair=1
-                           # (uses .shiply.json from CWD; pairs agent session to user's browser)
-```
-The CLI stores each directory's site in `.shiply.json` (slug + update token),
-so repeat publishes reuse the URL automatically. `--new-site` opts out.
-Gitignore `.shiply.json` in public repos. Parse `SITE_READY` / `SSL_READY`
-lines for automation; exit code 0 = ready. For a static framework build
-(Vite, Next export, Hugo, …) publish the BUILD OUTPUT, not the source — run
-`shiply detect` to see what the CLI found; the full framework matrix is in
-[references/publishing.md](references/publishing.md).
-
-### 3. Raw HTTP (no installs)
-```
-1. POST https://shiply.now/api/v1/publish   (Content-Type: application/json)
-   {
-     "agentName": "<your tool name, e.g. Claude Code, Cursor, Codex>",
-     "files": [{"path":"index.html","size":<bytes>,"contentType":"text/html","hash":"<sha256 lowercase hex, optional>"}]
-   }
-   (+ "Authorization: Bearer shp_…" for permanent owned sites)
-2. PUT each file's bytes to response upload.uploads[].url
-3. POST upload.finalizeUrl with {"versionId":"<upload.versionId from step 1>"}
-   → both the publish and finalize responses include a "toUpdate" string: the
-     exact call to update THIS site next time. Follow it — never create a new one.
-```
-
-**ALWAYS include `agentName` on anonymous publishes.** The response then
-carries `deviceAuth` ({user_code, verification_url, poll_url, device_code,
-expires_in, interval}) alongside `claimUrl`. Show the user `verification_url`,
-poll `poll_url` every `interval` seconds with the `device_code`, and on
-`{status:"approved"}` you get a permanent `api_key` PLUS the linked site
-is claimed in the same Allow click. Without `agentName` the user has to
-do a separate manual claim step every time.
-
-**Updates (the response tells you how):** every publish/finalize response
-includes a `toUpdate` string with the exact call — follow it verbatim. In short:
-anonymous → include `"claimToken":"..."` (returned ONCE by the first publish —
-save it); owned → include `"slug":"..."`. Hashes make updates cheap: unchanged
-files are skipped server-side.
-
-## Verify before you say "done"
-
-`shiply status <slug> --wait` polls until the site serves (exit 0, prints
-`SITE_READY` / `SSL_READY`). `shiply verify <slug>` runs a deeper edge
-SSL + HTTP + thumbnail check and prints a stable machine marker line
-`VERIFY status=LIVE http=200 ssl=valid …` — parse that line in automation.
-More manage commands (list, delete, rollback, promote, stable previews) are
-in [references/publishing.md](references/publishing.md).
-
-## The lifecycle to explain to users
-- Anonymous site: live immediately after finalize (no claim needed), expires
-  in 24 h. Give the user the `claimUrl` — claiming keeps it forever on a free
-  account. Until claimed, anonymous pages are served with a small injected
-  claim banner + OG meta tags — expected, not corruption. If no human is
-  present right now, save the `claimToken` (it's also the update key); a
-  fresh device flow can be started later via
-  POST /api/v1/auth/device/start {"agent_name":"..."}.
-- API key (`shiply login` or POST /api/auth/agent/request-code →
-  verify-code): publishes are permanent and manageable.
-- Paid plans add vanity handles (<name>.shiply.now), more custom domains,
-  storage, analytics: https://shiply.now/dashboard/plan
-
-## Everything else — read the topic file first
-
-The files below sit next to this one in `references/` (installed with the
-skill). Hosted copies: `https://shiply.now/skill/references/<file>`. Each is
-self-contained — read the one matching the task before improvising; each
-covers its CLI commands, MCP tools, AND REST endpoints.
-
-* [Publishing & site management](references/publishing.md) — static framework
-  build matrix (Vite/Next/Hugo/…), `detect`, SPA mode, `.shiplyignore`,
-  list/delete/rollback/versions, `verify`, stable previews (`--as`),
-  `promote` preview→prod, `--json` output, form-data subcommands.
-* [SSR frameworks](references/ssr-frameworks.md) — deploy SvelteKit, Astro,
-  Qwik, Nuxt/Nitro, React Router v7, Next.js (OpenNext), Hono/raw Workers
-  with server-side rendering.
-* [Custom domains](references/custom-domains.md) — put the user's own domain
-  on a site: one-click OAuth DNS, manual CNAME, primary-subdomain SEO,
-  readiness polling.
-* [Databases](references/databases.md) — per-site SQL: free D1 (SQLite at the
-  edge, browser shim) + Neon Postgres (branching), migrations, per-DB MCP
-  server.
-* [Functions](references/functions.md) — `worker.js` server code on every
-  request: webhooks, cron triggers, secrets, runtime logs (Workers Lite,
-  Developer plan).
-* [Email](references/email.md) — every owned site sends + receives: signup
-  capture, inbox, double-opt-in audiences, broadcasts, BYO sending domains.
-* [Site features](references/site-features.md) — proxy routes (call AI APIs
-  without exposing keys), Site Data (forms/waitlists, zero backend),
-  password/invite-only access, Variables, Drives (private storage),
-  path-mounting, public profile.
-* [Client work](references/client-work.md) — freelancer delivery: customer
-  intake projects + AI briefs, group work by client, e-sign contracts,
-  sell sites on the marketplace.
-* [Authentication for the user's app](references/site-features.md) — shiply
-  does NOT host end-user auth; bring the user's own Clerk/Auth.js/Supabase
-  (pattern in Site features → "Bring your own auth").
-
-## Limits & references
-≤1000 files/site (≤50 inline via MCP), ≤100 MiB/file, 1 GiB total.
-Machine index: https://shiply.now/llms.txt (full single-file version:
-https://shiply.now/llms-full.txt) · What's new: https://shiply.now/changelog.md
-· OpenAPI: https://shiply.now/openapi.json · Docs: https://shiply.now/docs
+---
+name: shiply
+description: "shiply is the production backend for anything an agent builds — publish any app (static or full-stack SSR, any framework) and give it a live URL, custom domain, SQL database, server functions, email, and a marketplace to sell it. Use when the user asks to publish, host, deploy, share, or update a website/page/demo/report/app, or wants a live URL for generated files. Triggers - \"publish this\", \"host this\", \"put this online\", \"give me a link\", \"update the site\", \"deploy my SvelteKit/Astro/Next.js app\", shiply."
+---
+
+---
+
+> **IMPORTANT — npm package name is `shiply-cli`, NOT `shiply`.** A different
+> npm package named `shiply` (an auto-commit watcher) is published by someone
+> else — installing it does NOT give you the shiply.now CLI. Always use
+> `npx -y shiply-cli@latest …` or `npm install -g shiply-cli`. The CLI binary
+> on PATH is still named `shiply` once installed; the warning is only about
+> the npm package name.
+
+> **Skill freshness check.** Shiply ships new capabilities weekly.
+> **This skill: version 0.27.0, last updated 2026-07-11.**
+> To see what changed since your copy was written, fetch
+> `https://shiply.now/changelog.md` (date-grouped, newest first) — if it lists
+> capabilities newer than the date above, re-install with
+> `npx -y shiply-cli@latest skill --force` OR read the live copy at
+> `https://shiply.now/skill.md`.
+
+---
+
+# shiply — the production backend for anything an agent builds
+
+**What it is.** Not static hosting. shiply takes whatever you build — a static page or a full-stack app in any framework — and gives it a live URL, a custom domain, a SQL database, server functions, email (send + receive), and a marketplace to sell it. One call. No account needed to start: anonymous sites are live immediately, last 24 hours, and can be claimed to keep.
+
+**Why use it.** Ship a complete, working product without stitching together a host + database + email + registrar + payments — it's one agent-native platform (MCP / CLI / REST parity). Hard-ceiling pricing ($0/$8/$24, plus a $49 Studio tier for client delivery — no usage meter on any tier), so a spike or DDoS can never become a surprise bill for the owner.
+
+**How (quickstart).** `shiply publish ./dir` (CLI) — or POST /api/v1/publish → PUT each file → POST finalize — returns a live URL + claimToken.
+
+**NEVER create a new site to update an existing one. Always re-publish to the
+same site** (same slug/claimToken) — otherwise you litter subdomains and lose
+the user's URL.
+
+**Re-publishing the same site is cheap — always prefer it over a new site.**
+Unchanged files are hash-skipped, and an unchanged SSR worker bundle skips
+redeploy entirely (fingerprinted against what's already live). A zero-change
+`shiply publish` on the same site completes in seconds, even for large SSR
+apps — so iterate freely by re-publishing, never by spinning up a fresh site.
+
+This file covers the core path: publish → authorize → update → claim → verify.
+Everything else (databases, domains, SSR, email, functions, client work) lives
+in the **topic files indexed at the bottom** — read the one that matches the
+task before improvising.
+
+## First publish on a new machine: ask for a permanent key in one step
+
+On a no-Bearer publish, include `"agentName": "<your-tool-name>"` in the body
+(e.g. `"Claude Code"`, `"Cursor"`). The response will include a `deviceAuth`
+object alongside the usual `claimUrl`:
+
+```
+"deviceAuth": {
+  "user_code": "ABCD-EFGH",
+  "device_code": "<long opaque token, keep private>",
+  "verification_url": "https://shiply.now/auth/ABCD-EFGH",
+  "poll_url": "https://shiply.now/api/v1/auth/device/poll",
+  "expires_in": 900,
+  "interval": 2
+}
+```
+
+Tell the user once, in plain language:
+
+> Your site is live at <siteUrl>. To keep it forever AND let me publish more
+> without re-pasting, open <verification_url> and click Allow.
+
+Then immediately poll `verification_url`'s sibling endpoint until the user
+acts:
+
+```
+POST https://shiply.now/api/v1/auth/device/poll
+{"device_code": "<the device_code from the response>"}
+```
+
+The response is one of `{status:"pending"}` (keep polling at `interval`s),
+`{status:"approved", api_key:"shp_...", slug_claimed:"..."}` (PERSIST the key —
+see "Save the key" below — the site is now permanent; Allow does both jobs in
+one click), `{status:"expired"|"denied"|"consumed"}` (stop). Cap your polling at
+the announced `expires_in` and respect `interval` — don't tight-loop.
+
+After approval, every future publish uses `Authorization: Bearer <api_key>`
+and the user's dashboard shows their sites without any further claiming.
+
+### Save the key — so EVERY future site is seamless (do this once)
+
+Write the key to **`~/.shiply/credentials`** as `{"apiKey":"shp_..."}` (chmod
+600) — the exact file the shiply CLI reads. This is what makes "one Allow, ever"
+work: from then on every publish (any site, any project, ANY FUTURE SESSION)
+sends `Authorization: Bearer <key>` automatically and lands owned in the user's
+dashboard — no re-authorizing, no claim step, zero clicks. An env var alone
+(`SHIPLY_API_KEY`) works for the current shell but does NOT survive a new
+session — the credentials file is what makes it permanent. `shiply login` writes
+this file for you; if you publish over raw HTTP, write it yourself.
+
+## When the user pastes you something shiply-shaped, do this
+
+These are the patterns you will see. Match the input, run the action — do not
+ask the user to repeat themselves or explain.
+
+- **Code like `SHIPLY-XXXXXXXX`** → it's a pairing code from
+  `shiply.now/claim/<slug>?pair=1`. The user wants to attach an anonymous
+  site to their account. Run `shiply claim verify SHIPLY-XXXXXXXX` from the
+  directory you originally published from (it reads `.shiply.json`). No CLI?
+  POST `https://shiply.now/api/v1/claim/pair/SHIPLY-XXXXXXXX/verify` with
+  `{"siteId":"...","claimToken":"..."}` taken from your earlier publish
+  response or `.shiply.json`. The user's browser auto-redirects on success;
+  tell them to switch back to it.
+- **URL like `https://shiply.now/claim/<slug>?token=...`** → one-click claim
+  link. Tell the user to open it in the browser they are signed in to —
+  do NOT call any API yourself.
+- **User says "claim my site" / "save it forever" with no code or URL** →
+  give them the `claimUrl` from your last publish response. If you no longer
+  have that response but `.shiply.json` is in the publish dir, reconstruct it
+  as `https://shiply.now/claim/<slug>?token=<claimToken>` from those fields.
+  Either way, also suggest `shiply login` so future publishes mint to their
+  account directly — that's the long-term fix and how the dashboard works.
+- **User says "I have an API key now, use it from now on"** → persist it to
+  `~/.shiply/credentials` (`{"apiKey":"shp_..."}`, chmod 600 — see "Save the
+  key" above), then send `Authorization: Bearer <key>` on every future publish.
+  All future sites are then permanent and appear in their dashboard
+  automatically — across sessions, with no re-authorizing.
+- **User opens an `https://shiply.now/auth/XXXX-YYYY` URL you printed** → no
+  action from you; they're on the device-flow consent screen. Keep polling
+  `poll_url` (see "First publish on a new machine" above). The poll response
+  will flip from `pending` to `approved` (with `api_key`) the moment they
+  click Allow.
+
+## Pick your interface (best first)
+
+### 1. MCP (native tools)
+If the `shiply` MCP server is connected (https://shiply.now/mcp), use
+`publish_site`. Every result includes a `toUpdate` field telling you the exact
+call for updates — follow it, and a `shareSuggestion` you can relay to the user.
+Core tools: `site_status`, `list_sites`, `get_site`, `delete_site`, `whoami`,
+`duplicate_site`, `set_variable`, `get_analytics`, `set_handle`. There are
+100+ tools in total — call `tools/list` for the authoritative set; the topic
+files below name the tools for their area (domains, databases, email,
+functions, projects, contracts, marketplace, drives).
+
+### 2. CLI
+```bash
+# IMPORTANT: the npm package is `shiply-cli`, not `shiply` (different package).
+npm i -g shiply-cli        # or: npx -y shiply-cli@latest <command>
+                           # or: curl -fsSL https://shiply.now/install.sh | bash
+shiply publish ./dir       # live URL + confetti
+shiply publish ./dir       # run AGAIN after edits → updates the SAME site
+shiply status <slug> --wait  # SSL + readiness; prints SSL_READY / SITE_READY
+shiply login               # email code → API key → sites become permanent
+shiply claim verify <code> # confirm a SHIPLY-XXXXXXXX pairing code from /claim/<slug>?pair=1
+                           # (uses .shiply.json from CWD; pairs agent session to user's browser)
+```
+The CLI stores each directory's site in `.shiply.json` (slug + update token),
+so repeat publishes reuse the URL automatically. `--new-site` opts out.
+Gitignore `.shiply.json` in public repos. Parse `SITE_READY` / `SSL_READY`
+lines for automation; exit code 0 = ready. For a static framework build
+(Vite, Next export, Hugo, …) publish the BUILD OUTPUT, not the source — run
+`shiply detect` to see what the CLI found; the full framework matrix is in
+[references/publishing.md](references/publishing.md).
+
+### 3. Raw HTTP (no installs)
+```
+1. POST https://shiply.now/api/v1/publish   (Content-Type: application/json)
+   {
+     "agentName": "<your tool name, e.g. Claude Code, Cursor, Codex>",
+     "files": [{"path":"index.html","size":<bytes>,"contentType":"text/html","hash":"<sha256 lowercase hex, optional>"}]
+   }
+   (+ "Authorization: Bearer shp_…" for permanent owned sites)
+2. PUT each file's bytes to response upload.uploads[].url
+3. POST upload.finalizeUrl with {"versionId":"<upload.versionId from step 1>"}
+   → both the publish and finalize responses include a "toUpdate" string: the
+     exact call to update THIS site next time. Follow it — never create a new one.
+```
+
+**ALWAYS include `agentName` on anonymous publishes.** The response then
+carries `deviceAuth` ({user_code, verification_url, poll_url, device_code,
+expires_in, interval}) alongside `claimUrl`. Show the user `verification_url`,
+poll `poll_url` every `interval` seconds with the `device_code`, and on
+`{status:"approved"}` you get a permanent `api_key` PLUS the linked site
+is claimed in the same Allow click. Without `agentName` the user has to
+do a separate manual claim step every time.
+
+**Updates (the response tells you how):** every publish/finalize response
+includes a `toUpdate` string with the exact call — follow it verbatim. In short:
+anonymous → include `"claimToken":"..."` (returned ONCE by the first publish —
+save it); owned → include `"slug":"..."`. Hashes make updates cheap: unchanged
+files are skipped server-side.
+
+## Verify before you say "done"
+
+`shiply status <slug> --wait` polls until the site serves (exit 0, prints
+`SITE_READY` / `SSL_READY`). `shiply verify <slug>` runs a deeper edge
+SSL + HTTP + thumbnail check and prints a stable machine marker line
+`VERIFY status=LIVE http=200 ssl=valid …` — parse that line in automation.
+More manage commands (list, delete, rollback, promote, stable previews) are
+in [references/publishing.md](references/publishing.md).
+
+## The lifecycle to explain to users
+- Anonymous site: live immediately after finalize (no claim needed), expires
+  in 24 h. Give the user the `claimUrl` — claiming keeps it forever on a free
+  account. Until claimed, anonymous pages are served with a small injected
+  claim banner + OG meta tags — expected, not corruption. If no human is
+  present right now, save the `claimToken` (it's also the update key); a
+  fresh device flow can be started later via
+  POST /api/v1/auth/device/start {"agent_name":"..."}.
+- API key (`shiply login` or POST /api/auth/agent/request-code →
+  verify-code): publishes are permanent and manageable.
+- Paid plans add vanity handles (<name>.shiply.now), more custom domains,
+  storage, analytics: https://shiply.now/dashboard/plan
+
+## Everything else — read the topic file first
+
+The files below sit next to this one in `references/` (installed with the
+skill). Hosted copies: `https://shiply.now/skill/references/<file>`. Each is
+self-contained — read the one matching the task before improvising; each
+covers its CLI commands, MCP tools, AND REST endpoints.
+
+* [Publishing & site management](references/publishing.md) — static framework
+  build matrix (Vite/Next/Hugo/…), `detect`, SPA mode, `.shiplyignore`,
+  list/delete/rollback/versions, `verify`, stable previews (`--as`),
+  `promote` preview→prod, `--json` output, form-data subcommands.
+* [SSR frameworks](references/ssr-frameworks.md) — deploy SvelteKit, Astro,
+  Qwik, Nuxt/Nitro, React Router v7, Next.js (OpenNext), Hono/raw Workers
+  with server-side rendering.
+* [Custom domains](references/custom-domains.md) — put the user's own domain
+  on a site: one-click OAuth DNS, manual CNAME, primary-subdomain SEO,
+  readiness polling.
+* [Databases](references/databases.md) — per-site SQL: free D1 (SQLite at the
+  edge, browser shim) + Neon Postgres (branching), migrations, per-DB MCP
+  server.
+* [Functions](references/functions.md) — `worker.js` server code on every
+  request: webhooks, cron triggers, secrets, runtime logs (Workers Lite,
+  Developer plan).
+* [Email](references/email.md) — every owned site sends + receives: signup
+  capture, inbox, double-opt-in audiences, broadcasts, BYO sending domains.
+* [Site features](references/site-features.md) — proxy routes (call AI APIs
+  without exposing keys), Site Data (forms/waitlists, zero backend),
+  password/invite-only access (`shiply access <slug> --password <pw>` /
+  `--restricted --email a@b.com` / `--public`), Variables, Drives (private
+  storage), path-mounting, public profile.
+* [Client work](references/client-work.md) — freelancer delivery: customer
+  intake projects + AI briefs, group work by client, e-sign contracts,
+  sell sites on the marketplace.
+* [Authentication for the user's app](references/site-features.md) — shiply
+  does NOT host end-user auth; bring the user's own Clerk/Auth.js/Supabase
+  (pattern in Site features → "Bring your own auth").
+
+## Limits & references
+≤1000 files/site (≤50 inline via MCP), ≤100 MiB/file, 1 GiB total.
+Machine index: https://shiply.now/llms.txt (full single-file version:
+https://shiply.now/llms-full.txt) · What's new: https://shiply.now/changelog.md
+· OpenAPI: https://shiply.now/openapi.json · Docs: https://shiply.now/docs

package/skill/references/site-features.md

@@ -44,7 +44,12 @@ see [email.md](email.md).
 
 ## Access control — password or invite-only sites (paid)
 
-To password-protect or restrict a site: PATCH /api/v1/publishes/<slug>/access
+CLI (preferred): `shiply access <slug>` prints the current policy (plus a
+stable `ACCESS slug=… mode=…` marker line); set it with
+`shiply access <slug> --password "..."`, `--restricted --email a@b.com
+--domain example.com` (both flags repeatable — each set REPLACES the previous
+lists), or `--public` to open it up.
+REST: PATCH /api/v1/publishes/<slug>/access
 with {"mode":"password","password":"..."} or {"mode":"restricted",
 "allowedEmails":[...],"allowedDomains":[...]}, or set mode "public" to open it.
 GET returns the policy (never the hash). MCP tool: `set_site_access`. Enforced

package/skill/references/ssr-frameworks.md

@@ -1,57 +1,57 @@
----
-type: reference
-title: SSR frameworks
-description: Deploy full server-side-rendered apps — SvelteKit, Astro, Qwik, the Nitro family (Nuxt, SolidStart, Analog, TanStack Start), React Router v7, Next.js via OpenNext, and Hono/raw Workers.
-timestamp: 2026-07-04
----
-
-# SSR / server frameworks (live: every major JS framework)
-
-Part of the shiply skill (see SKILL.md for publish basics). Requires sign-in +
-Developer plan.
-
-`shiply publish` auto-detects an SSR build and deploys the worker bundle with
-`nodejs_compat`, serving static assets from the edge. Live and verified on prod:
-SvelteKit (`@sveltejs/adapter-cloudflare`), Astro (`@astrojs/cloudflare`), Qwik
-City, the Nitro family (Nuxt, SolidStart, Analog, TanStack Start), React Router
-v7, and Next.js (via OpenNext) — plus wrangler workers (`wrangler.toml` with
-`main` — Hono, itty-router, raw `fetch`). **Build first** (`npm run build`),
-then `shiply publish .`. Force the static path with `--framework=<name>`, or
-skip SSR detection entirely with `--no-ssr`.
-
-Per-framework build setup:
-
-- **SvelteKit** — `@sveltejs/adapter-cloudflare`, then `npm run build`,
-  `shiply publish .`
-- **Astro** — `@astrojs/cloudflare` adapter, `npm run build`, `shiply publish .`
-- **Qwik City** — `@builder.io/qwik-city` cloudflare-pages adapter,
-  `npm run build`, `shiply publish .`
-- **Nitro family (Nuxt, SolidStart, Analog, TanStack Start)** — build with the
-  `cloudflare`(-module) Nitro preset, then `shiply publish .`
-- **React Router v7** — framework mode (`@react-router/dev`), `react-router
-  build`, then `shiply publish .`
-- **Next.js** — build via `@opennextjs/cloudflare` (OpenNext), then
-  `shiply publish .`. Plain SSR works today; **ISR / on-demand revalidate is
-  not live yet**, and Next 16 must build with `next build --webpack` (not
-  Turbopack). `shiply publish` runs a **PREFLIGHT** on Next source dirs: it
-  auto-fixes Turbopack build scripts, translates `vercel.json` crons to
-  `.shiply/crons.json`, and refuses to publish raw source with no worker
-  build — read its `FIX`/`WARN` lines, do what they say, re-run.
-
-  Publish output is self-describing — trust it over memory: finalize streams
-  per-phase progress lines, a failed worker deploy prints a structured `fix:`
-  line to execute verbatim, and after every worker deploy the server probes
-  the live site — a non-zero exit with a `runtime error:` line means
-  DEPLOYED BUT BROKEN (the actual worker exception + likely fix are printed,
-  e.g. a missing `shiply secret set`); fix the printed cause and republish.
-- **Wrangler workers** — any repo with `wrangler.toml` declaring `main`
-  (Hono, itty-router, raw `fetch` handler) deploys as-is.
-
-How serving works: the deployed worker receives every request; static assets
-are tried first (the worker calls `env.ASSETS`, 200 = asset served from the
-edge / 404 = your SSR handler runs). The worker gets the same bindings,
-secrets, and crons as Functions — see [functions.md](functions.md). Bundle
-cap 8 MB.
-
-Plan gate: Free/Hobby get `402 payment_required` — upgrade at
-https://shiply.now/dashboard/plan.
+---
+type: reference
+title: SSR frameworks
+description: Deploy full server-side-rendered apps — SvelteKit, Astro, Qwik, the Nitro family (Nuxt, SolidStart, Analog, TanStack Start), React Router v7, Next.js via OpenNext, and Hono/raw Workers.
+timestamp: 2026-07-04
+---
+
+# SSR / server frameworks (live: every major JS framework)
+
+Part of the shiply skill (see SKILL.md for publish basics). Requires sign-in +
+Developer plan.
+
+`shiply publish` auto-detects an SSR build and deploys the worker bundle with
+`nodejs_compat`, serving static assets from the edge. Live and verified on prod:
+SvelteKit (`@sveltejs/adapter-cloudflare`), Astro (`@astrojs/cloudflare`), Qwik
+City, the Nitro family (Nuxt, SolidStart, Analog, TanStack Start), React Router
+v7, and Next.js (via OpenNext) — plus wrangler workers (`wrangler.toml` with
+`main` — Hono, itty-router, raw `fetch`). **Build first** (`npm run build`),
+then `shiply publish .`. Force the static path with `--framework=<name>`, or
+skip SSR detection entirely with `--no-ssr`.
+
+Per-framework build setup:
+
+- **SvelteKit** — `@sveltejs/adapter-cloudflare`, then `npm run build`,
+  `shiply publish .`
+- **Astro** — `@astrojs/cloudflare` adapter, `npm run build`, `shiply publish .`
+- **Qwik City** — `@builder.io/qwik-city` cloudflare-pages adapter,
+  `npm run build`, `shiply publish .`
+- **Nitro family (Nuxt, SolidStart, Analog, TanStack Start)** — build with the
+  `cloudflare`(-module) Nitro preset, then `shiply publish .`
+- **React Router v7** — framework mode (`@react-router/dev`), `react-router
+  build`, then `shiply publish .`
+- **Next.js** — build via `@opennextjs/cloudflare` (OpenNext), then
+  `shiply publish .`. Plain SSR works today; **ISR / on-demand revalidate is
+  not live yet**, and Next 16 must build with `next build --webpack` (not
+  Turbopack). `shiply publish` runs a **PREFLIGHT** on Next source dirs: it
+  auto-fixes Turbopack build scripts, translates `vercel.json` crons to
+  `.shiply/crons.json`, and refuses to publish raw source with no worker
+  build — read its `FIX`/`WARN` lines, do what they say, re-run.
+
+  Publish output is self-describing — trust it over memory: finalize streams
+  per-phase progress lines, a failed worker deploy prints a structured `fix:`
+  line to execute verbatim, and after every worker deploy the server probes
+  the live site — a non-zero exit with a `runtime error:` line means
+  DEPLOYED BUT BROKEN (the actual worker exception + likely fix are printed,
+  e.g. a missing `shiply secret set`); fix the printed cause and republish.
+- **Wrangler workers** — any repo with `wrangler.toml` declaring `main`
+  (Hono, itty-router, raw `fetch` handler) deploys as-is.
+
+How serving works: the deployed worker receives every request; static assets
+are tried first (the worker calls `env.ASSETS`, 200 = asset served from the
+edge / 404 = your SSR handler runs). The worker gets the same bindings,
+secrets, and crons as Functions — see [functions.md](functions.md). Bundle
+cap 8 MB.
+
+Plan gate: Free/Hobby get `402 payment_required` — upgrade at
+https://shiply.now/dashboard/plan.