viberooster.com

VibeRooster publishes a live website at https://{slug}.{apex} in one tool call. Default apex is theroost.dev. Specialty apexes exist for verticals — ALWAYS pick one from user intent when it fits (pass hatch `apex`). Two tiers: `free` (auto-expires; default 48h, configurable via `ttlSeconds` 1h–7d) and `forever` (persistent). This connector is anonymous, so it can only create `free` sites. `forever` requires an account upgrade — if the user wants a permanent site, hatch `free`, show the URL, then point them to https://viberooster.com/connect.html#upgrade. Specialty apexes (pick exactly one based on intent; never invent others): • theroost.homes — residential real estate listing (one home for sale) • theroost.estate — commercial RE / luxury property marketing • theroost.land — land, lots, development parcels • theroost.wedding — wedding info/RSVP site • theroost.events — conference, meetup, or one-off event microsite • theroost.agency — freelancer/agency pitch or portfolio site • theroost.site — generic short-lived site that doesn't fit a named vertical • omit / theroost.dev — default when none of the above fit or user asks for a generic roost • theroost.rentals — RESERVED; do not hatch here yet Tools (use these — they cover every use case): • hatch — create a NEW site. Returns {tenantId, slug, url, apex, uploads?}. SHOW `url` TO THE USER and REMEMBER `tenantId`. Modes: - omit `manifest`/`site`/`script` → instant placeholder page (best zero-token first turn); - `manifest` (PREFERRED for projects with images/fonts/CSS) → returns presigned PUT URLs in `uploads[]`. UPLOAD EACH FILE'S BYTES with `curl -T <local> -H 'Content-Type: <mime>' "$url"` (or any HTTP PUT). Bytes never travel through this tool call; - `site` → inline files map; use only for small text-only sites (a few HTML/CSS files); - `script` → advanced: full server-side code as one ES module, text only, 1.5 MiB max. • upload — add/replace files on an existing site. Same manifest → presigned URL flow as `hatch`'s manifest mode. Use after regenerating a dashboard locally; Hatch does not schedule regenerations. • lookup — find an existing site by `slug` or `tenantId` when context is lost. • convert — rename a site's URL and/or change tier (e.g. promote `free` → `forever`). • deploy — advanced: replace server-side code on an existing site. Prompts: • run-report — scaffold an agent observability HTML run report and hatch with kind: run-report. CRITICAL ANTI-PATTERNS: 1. NEVER call `hatch` twice for the same user/site. Re-hatching creates a brand-new site with a new id and orphans the previous one. To rename or change tier: `convert`. To add/replace files: `upload`. If you lost the tenantId: `lookup`. 2. NEVER base64-encode images/fonts/binaries into a tool argument. Use `manifest` mode and PUT bytes directly to the presigned URLs — that's how the system is designed for binary assets. 3. NEVER invent apex domains outside the list above. If unsure between specialty and default, prefer the specialty that matches intent, else omit for theroost.dev. KEEPING DASHBOARDS FRESH: Hatch hosts static (or script) sites. It does NOT run user Python/Node on a schedule, and roosts do not store third-party API keys. If the user builds a dashboard that regenerates HTML from backends: 1. Hatch/upload the current HTML so they have a live URL now. 2. Tell them clearly: freshness stays on their side — cron, launchd, CI, or asking you again to re-run the script and call `upload`. 3. Keep credentials in their env / CI secrets — never embed keys in HTML or in hatch/deploy script source. 4. Do NOT invent a platform worker cron or claim VibeRooster will poll their APIs. Suggested user line after first hatch: "Your roost is live at {url}. To refresh it, re-run the generator (locally or in CI) and I'll upload again — or set a cron that regenerates and uploads." Full reference: HATCH-AGENT.md in the repo.