Name: here-now
Author: heredotnow

here.now lets agents publish websites and files to live URLs in seconds. Publish HTML, documents, images, PDFs, videos, and static files to live URLs at {slug}.here.now or custom domains. Use when asked to "publish this", "host this", "deploy this", "share this on the web", "make a website", "put th

here.now Skill version: 1.34.0 here.now lets agents publish websites and files to live URLs in seconds. The core primitive is a Site : publish a file or folder and get a live URL at {slug}.here.now or a custom domain. Every Site has access control: public link (default), password, or restricted invite only access. here.now also includes workspaces — shared team accounts where Sites belong to the team and serve at {label}.{workspace}.here.now (see "Publish to a workspace" below). A personal account on a paid plan can turn on a vanity URL : the user's name at {name}.here.now , and from then on every Site they publish (including through you) also serves at a readable {site name}.{name}.here.now address, named from its title. When a user wants every Site under their own name, PUT /api/v1/vanity urls/subdomain with {"subdomain": "name"} turns it on; for one Site at one hostname they choose, use a custom domain; for Sites owned by a team, use a workspace. Finalize responses carry primaryUrl and urls[] (best first); mention primaryUrl when it differs from siteUrl . See https://here.now/docs vanity urls. To install or update (recommended): npx skills add heredotnow/skill skill here now g For repo pinned/project local installs, run the same command without g . Current docs Before answering questions about here.now capabilities, features, or workflows, read the current docs: → https://here.now/docs Read the docs: at the first here.now related interaction in a conversation any time the user asks how to do something any time the user asks what is possible, supported, or recommended before telling the user a feature is unsupported Topics that require current docs (do not rely on local skill text alone): Site access control (passwords and restricted access) workspaces (team accounts, membership, label URLs) folders (organizing the user's dashboard; see https://here.now/docs folders) Drives and Drive sharing custom domains vanity URLs ( {site name}.{name}.here.now ; see https://here.now/docs vanity urls) buying a domain (search and quote first; state the price and the renewal price and get the user's explicit yes before calling purchase — purchases are final; see https://here.now/docs buy domain) Site Data public profiles proxy routes and service variables limits and quotas SPA routing owner Site search Site analytics Site version history, previews, and rollback error handling and remediation feature availability If docs and live API behavior disagree, trust the live API behavior. Command line fetches of https://here.now/docs (curl, WebFetch, etc.) receive a markdown summary, not the full HTML docs: it lists every stable public endpoint with a one line description, but section anchors in this skill (like /docs access control ) resolve only in the HTML version, and worked examples live there too. For complete request/response schemas and parameters, fetch https://here.now/openapi.json . Do not conclude an operation is unsupported from the markdown summary alone — check the OpenAPI spec first. If the docs fetch fails or times out, continue with the local skill and live API/script output. Prefer live API behavior for active operations. Requirements Required binaries: curl , file , jq Required network access: https://here.now (API) and https:// .r2.cloudflarestorage.com (file uploads PUT directly to storage; the exact host is in each upload URL). In a sandbox or behind a proxy with an egress allowlist, allow BOTH hosts. With only here.now allowed, the create call succeeds, every upload fails, and finalize reports missing files. Optional environment variable: $HERENOW API KEY Optional Drive token variable: $HERENOW DRIVE TOKEN Optional credentials file: ~/.herenow/credentials Bundled helpers: ./scripts/publish.sh for publishing sites ./scripts/drive.sh for private Drive storage If the helper scripts aren't installed Some environments receive this document without the bundled scripts/ directory (for example, hosted platform integrations that provide only $HERENOW API KEY ). In that case, either install the full bundle first: or call the API directly — every script workflow in this document is a wrapper over the public API. Publishing is a three step flow: POST /api/v1/publish with a files array ( [{path, size}] ) returns presigned upload targets, PUT each file's bytes to its returned URL, then POST the returned finalizeUrl . The site is not live until finalize succeeds. Full walkthrough with request/response examples: https://here.now/docs create (then upload and finalize), machine readable schemas: https://here.now/openapi.json. Create a site Outputs the live URL (e.g. https://bright canvas a7k2.here.now/ ). Under the hood this is a three step flow: create/update upload files finalize. A site is not live until finalize succeeds. Without an API key this creates an anonymous site that expires in 24 hours. With a saved API key, the site is permanent. File structure: For HTML sites, place index.html at the root of the directory you publish, not inside a subdirectory. The directory's contents become the site root. For example, publish my site/ where my site/index.html exists — don't publish a parent folder that contains my site/ . You can also publish raw files without any HTML. Single files get a rich auto viewer (images, PDF, video, audio). Multiple files get an auto generated directory listing with folder navigation and an image gallery. WebAssembly builds (Emscripten, Rust, Godot, Unity, Pyodide, WebLLM, ...) publish like any folder: point the script at the build output directory and it runs, with .wasm served and compressed correctly. If the build uses threads (SharedArrayBuffer: Emscripten pthread , Godot with Thread Support on, Unity multithreading), pass cross origin isolation ; single threaded builds need nothing. A publish result.warning= line mentioning WebAssembly means the Site has .wasm but the setting is off. Details and trade offs: https://here.now/docs wasm Update an existing site The script auto loads the claimToken from .herenow/state.json when updating anonymous sites. Pass claim token {token} to override. Authenticated updates require a saved API key. Stale base protection. The live Site may have changed since your local files were published — the owner can edit it from other tools (another agent, the here.now Editor, a teammate). The script records the live versionId in .herenow/state.json after each publish and sends it as baseVersionId on the next update of the same slug from the same directory; if the live Site moved past it, the update is rejected with code: "version conflict" naming the live version and what created it. When that happens, relay the message to the user and offer to (a) read the live files with GET /api/v1/publish/{slug}/files (lists them with a url each) and GET /api/v1/publish/{slug}/files/{path} (the bytes; owner API key, works for password protected and restricted Sites without the visitor password), reconcile them into the local files, and republish, or (b) re run with overwrite to replace the live version anyway. Before editing local files for an authenticated Site you haven't touched recently, check for drift first: GET /api/v1/publish/{slug} returns currentVersionId plus currentVersionSource and currentVersionCreatedAt (what changed it and when, e.g. editor ) — if the id differs from your state file's versionId , read the live files before editing. The published version is the shared truth; never fetch the public URL to read an owned Site (it is gated for protected Sites) and never ask the user for a visitor password to read their own Site. Anonymous Sites can't call these endpoints; they rely on the saved state and server enforcement. Omitting baseVersionId (or using overwrite ) is an unchecked full replacement — today's default for raw API callers. Every publish records an immutable version. If the user asks to see earlier versions of a Site, undo a publish, or roll back: list history with GET /api/v1/publish/{slug}/versions and restore instantly with POST /api/v1/publish/{slug}/versions/{versionId}/restore (restoring keeps the current access mode, password, and domains). Version access is included on every plan, personal and workspace alike. A byte identical republish returns unchanged: true from finalize instead of creating a new version. See https://here.now/docs versions. Signed in users also have public profiles. Agents can help users show or hide Sites on their profile and manage profile settings through the API documented at https://here.now/docs profile. Publish to a workspace Workspaces are shared team accounts: Sites published into one belong to the team, not the publishing member, and get a memorable URL at {label}.{workspace}.here.now . Requires a saved API key and membership in the workspace. List the user's workspaces (and valid subdomains) with GET /api/v1/accounts . Workspace Sites default to member only access; the script reports the team URL as publish result.account url . For everything else — creating workspaces, invites and auto join, workspace domains and variables, label renames — read the current docs: → https://here.now/docs workspaces Site access control A Site uses one access mode at a time: anyone with link (default): anyone with the URL can view. password : visitors must enter a shared password. restricted : invite only; only verified email addresses or email domains the owner allows can view. Workspace owned Sites default to account members (visitors sign in and must be workspace members) and also support public, public with a password, and restricted . On a workspace Site, restricted means workspace members plus a per Site guest allowlist: members always have access, and allowlisted emails/domains are outside guests who can view only that Site — they never become workspace members, though the Site appears in the guest's own dashboard as a shared Site. Workspace restricted requires at least one guest email or domain — an empty allowlist is rejected with a 400 (use account members for members only). See https://here.now/docs workspace access. Manage access with GET / PATCH /api/v1/publish/{slug}/access (passwords via the metadata endpoint). Restricted access requires a claimed Site. The PATCH replaces the full allowlists — read, merge, then write. Before working with access control, read the current docs: → https://here.now/docs access control Folders (organizing the user's dashboard) Signed in users can group their Sites into folders in the here.now dashboard. A folder is a fact about the account, not the Site's address: flat (no nesting), one folder per Site, shared by every member of a workspace, invisible to visitors. Filing a Site changes nothing about its URL or access. When the user names a folder, project, or client for a Site ("publish this to my Reports folder", "file it under Acme"), file it as part of the publish: folder takes a folder name or id. A name is matched case insensitively and created if it does not exist yet , so this works the first time; the script reports the result as publish result.folder . It requires an API key (anonymous Sites have no account to file in) and works with slug (moves an existing Site) and workspace (the workspace's folders). Without the script, the same field is folder on POST /api/v1/publish , PUT /api/v1/publish/{slug} , and PATCH /api/v1/publish/{slug}/metadata (the way to file a Site without publishing a new version; "folder": null moves it back to the root). GET /api/v1/folders lists the account's folders; GET /api/v1/publishes?folder={name or id} lists one folder's Sites. Rename and delete are PATCH / DELETE /api/v1/folders/{id} (del