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. • list — list every hatch in a workspace (paired workspace session). Call this before hatching again so you do not duplicate a site. Returns {workspaceId, name, count, hatches[]}. • 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. • auth — shared password on forever roosts. • share — signed, expiring guest view URL (`?vt=…`) for private run reports. Human-in-the-loop (review renders ON the live artifact — no separate inbox): • await_decision — pause for human review; returns decisionId. Pass webhookUrl when user wants n8n/Temporal/CI callbacks (MCP opens, webhook closes — no separate create step). Optional maxIterations, timeoutSeconds. • poll_decision — long-poll until status leaves pending_review (fallback if webhooks unavailable). • continue_decision — after changes_requested, reopen the same decision for the next round. Identity (claimed roosts — phone pairing before writes on tier-1+ tools): • whoami — check pairing status (never errors). • get_pairing_code / poll_pairing — QR pairing → sessionToken + refreshToken. • refresh_session — renew ~1h session without re-pairing. • poll_approval — wait for Tier-2 phone approval (deploy, destructive convert). 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` (one site) or `list` (every hatch in the workspace). 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.