You were sent here by your human
This page is addressed to you, the agent. It is a short protocol. Follow it in order and say the things it tells you to say. Do not start building until step 4.
Step 1 — Ask before doing anything
Ask your human these two questions, together, in one message, and wait for the answers:
1. Do you want me to install its skill and get set up now?
2. Where is the key file you were given? (It is a small text file, usually
sites-key-<name>.txt in your Downloads.)”
If the answer to 1 is no, stop here. If they do not have a key file, tell them to ask Roark for one, and stop.
Step 2 — Read the key file
It is plain text with two values. Lines starting with # are comments.
# sites (closed alpha) — key for <name>
HUB_URL=https://lnh25l18k1.execute-api.us-west-2.amazonaws.com
HUB_KEY=sites_xxxxxxxx_…
Put both values into the environment you run in: append them as exports to the human's shell profile (and Claude Code's environment if it has one). If you have no shell or no persistent environment, do not try to store them anywhere else: read the key file again at the start of each session and keep the two values in working memory only. Never copy them into a project, an .env file or a repository. Never echo the key. Then tell the human where the file should live: somewhere safe, never inside a project.
Step 3 — Install the skill
Claude Code:
claude plugin marketplace add rkz211/rkz_app_web_backend
claude plugin install hub-storage@rkz-hub
Any other agent (Grok, GPT, Gemini, anything that can fetch a URL): there is nothing to install. Fetch the skill file and treat it as your instructions whenever a site needs storage: SKILL.md. It is plain markdown: when to use sites, a copy-paste client with no dependency, patterns for Next.js, the rules. If you keep notes or memory across sessions, save that URL and the location of the key file.
Then say:
Step 4 — Build
sites is the host. There is no Vercel and no other host. It builds and serves the project from its source, Next.js with server code or a static build alike. For each project the skill has you:
- create a site:
POST $HUB_URL/sites {"name": …}withAuthorization: Bearer $HUB_KEY. Keep thesiteIdin the project as.sites/site(not a secret). From then on your key plus the headerX-Site: <siteId>does everything on that site; ignore the token in the response; - deploy:
POST /deploygives you an upload url;PUTthe zipped project there;POST /deploy/{id}/start; pollGET /deploy/{id}untillive(about three minutes; the build log is in the response if it fails); - the site is at
https://<siteId>.cookiejar.lol/. The deployed server already hasHUB_URLand its ownHUB_TOKEN, so records and files work from server code with no setup.PUT /envsets any other variables. Add the user's own domain withPOST /edge/domains {"domain":"www.example.com"}: when the zone is in our registrar account the DNS is written for you; otherwise the reply'smanuallist is the records for the human to create. PollGET /edge/domainsforlive. All of these: your key +X-Site.
To check what your key is and which sites it has made: GET $HUB_URL/key and GET $HUB_URL/sites. Each site there carries buildId (the deploy serving now) and modifiedAt (the last time what it serves changed); remember the pair and compare to know whether a site changed since you last looked.
Moved on 2026-09-22: sites.fictionfactory.ai → cookiejar.lol
If you set up before this date, nothing you hold changes: same HUB_URL, same key, same site ids. Every site now answers at https://<siteId>.cookiejar.lol/; its old <siteId>.sites.fictionfactory.ai name keeps working. Use the new name from now on in links you hand your human, and if you saved the old agent page url, replace it with https://cookiejar.lol/agent/. The skill file url is unchanged.
Rules you are held to
- Do not install a database, Postgres, Supabase, KV, Blob storage or an ORM, and do not deploy to Vercel, Netlify or any other host, for a sites project. If a requirement genuinely needs one, say so and ask.
HUB_KEYlives only in your own environment. Projects hold only their site id. Site tokens are minted per deploy and stay on the server.- Nothing from sites is exposed to the browser: no key, no site token in page code.
- If a call fails, report the request and the
{error}you got back to your human; do not retry 4xx errors.
Reference
| Auth | Authorization: Bearer $HUB_KEY + X-Site: <siteId> for anything on one of your sites; the key alone for /key and /sites |
|---|---|
| Route list | GET https://lnh25l18k1.execute-api.us-west-2.amazonaws.com/, no auth |
| Contract | README |
| Records | /c/{collection}/{key} — PUT, GET, DELETE; list with ?prefix=&limit=&cursor=; POST to a collection for a generated key |
| Files | /files/{public|private|site} — presigned upload, info + url, list, delete |
| Hosting | POST /deploy → upload source zip → POST /deploy/{id}/start → GET /deploy/{id}; live at <siteId>.cookiejar.lol; PUT /env for variables; POST /edge/domains {"domain":"…"} for your own domain (DNS written for you on our registrar; GET /edge/domains shows live) |
| Changed? | GET /sites/{siteId} (key) or GET /me (key + X-Site) → buildId + modifiedAt; GET /deploy/{buildId} for that build's log |
| Errors | {error} with a real status: 400, 401, 403, 404, 405, 409, 413 |
If something is wrong
Tell Roark, with the request that failed and the error text. A leaked key: say so at once; only the admin can replace it. Site tokens never leave the server; a redeploy rotates them.