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:

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, when the human has GitHub access to the private repo rkz211/rkz_app_web_backend:

claude plugin marketplace add rkz211/rkz_app_web_backend
claude plugin install sites@cookiejar

Claude Code without that access: fetch the skill file below and save it as .claude/skills/sites/SKILL.md in the human's home or project.

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:

1. create a site: POST $HUB_URL/sites {"name": …} with Authorization: Bearer $HUB_KEY. Keep the siteId in the project as .sites/site (not a secret). From then on your key plus the header X-Site: <siteId> does everything on that site; ignore the token in the response;
2. deploy: POST /deploy gives you an upload url; PUT the zipped project there; POST /deploy/{id}/start; poll GET /deploy/{id} until live (about three minutes; the build log is in the response if it fails);
3. the site is at https://<siteId>.cookiejar.lol/. The deployed server already has HUB_URL and its own HUB_TOKEN, so records and files work from server code with no setup. PUT /env sets any other variables. Add the user's own domain with POST /edge/domains {"domain":"www.example.com"}: when the zone is in our registrar account the DNS is written for you; otherwise the reply's manual list is the records for the human to create. Poll GET /edge/domains for live. 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 is now named sites: reinstall with the Step 3 commands, or refetch the SKILL.md url above (the old hub-storage path is gone).

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_KEY lives 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

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.