--- name: vvibe version: 1.0.0 description: vvibe is an operations console for AI coding agents. This skill teaches you how to connect to vvibe, install skills into yourself, and deploy demos via InsForge. homepage: https://oss-180.staging.vvibe.ai --- # vvibe — Agent Setup Skill You are an AI coding agent (Claude Code, Cursor, Codex, Cline, etc.) helping a user build, monitor, or extend their business through **vvibe**. This document is the canonical entry point — read it once, then proceed with the workflow that matches what the user asked for. ## What vvibe is, in one line > The GUI for your Product Agent — a dashboard the user (a non-technical creator) uses to monitor and configure what their AI agent (you) does on their behalf. The user is the **principal**. You are the **actor**. The dashboard is **observability**, not a click-driven CRUD console. ## How you'll be connected to vvibe You connect to vvibe over **MCP (HTTP transport)**. Run the login yourself — the human only has to approve a sign-in, not configure anything: ```bash npx @vvibe/cli login --server=https://vvibe-mcp-staging.fly.dev ``` This opens a browser sign-in page (and always prints the URL too, in case it doesn't open) — ask the human to approve it there. That's the only step that needs them: once they approve, the CLI mints a long-lived credential and writes the `vvibe` MCP server straight into your agent's config (Claude Code / Cursor / Codex). Every session after that — including headless / CI, with no human watching — just works with no further browser step. - MCP server: `https://vvibe-mcp-staging.fly.dev` - Transport: HTTP - Auth: one browser approval via `npx @vvibe/cli login`, then a long-lived credential — nothing to paste, and it keeps working headless Key MCP tools you'll see: - `vibe_list_skills` — fetch the live skill catalog - `vibe_report_skill_installed` — call this after you successfully `npx skills add` a skill, so the dashboard reflects the install - `vibe_fetch_pending_tasks` — pull queued health-check / sync tasks the user assigned - `vibe_report_health_check` — send back a structured health-check result ## Installing vvibe skills into yourself All vvibe skills live in one public repo: Install one or more in a single command: ```bash npx skills add vvibe/vvibe-skills --skill --yes ``` The `--yes` flag bypasses the interactive agent-selection prompt; required because you're an agent, not a human. After installing, **always** report back via MCP: ``` vibe_report_skill_installed({ skillId: "" }) ``` The dashboard reads this to show installation state and version drift. ### Skill catalog (live) | ID | Install package | Category | What it does | |---|---|---|---| | `analytics` | `vvibe-analytics` | data | Connects web analytics (Google Analytics 4, PostHog, or Mixpanel) to surface traffic, audience, and campaign data, and instruments VVibe's canonical event contract (checkout, product/page views, conversion funnels) against whichever provider the creator uses. Covers utm tracking at the traffic / session level (acquisition reports), plus identity (user_id) and event deduplication. For signup-time first-touch attribution per user, install the member skill alongside. Add to measure what content and promotions drive growth. Requires `appBaseUrl` to be set (via `vibe_update_brand` or dashboard Settings) before the skill can operate. | | `member` | `vvibe-member` | ops | Manages subscriber and member accounts — listings, segmentation, activity history, admin queries — and now also captures first-touch attribution (utm_*, referrer) at signup so creators can see where each paying user originally came from. Add to know your audience, act on it, and attribute growth to specific traffic sources / partners. | | `sentry` | `vvibe-sentry` | security | Runs a pre-deploy security audit on the creator's codebase by orchestrating gitleaks (secret leaks), osv-scanner + npm audit (dependency CVEs), semgrep (OWASP / JS / TS static analysis), and a small VVibe-integration layer. Normalises every finding into a CRITICAL / WARNING / INFO grade and reports the summary back to the dashboard via vibe_report_health_check. Add when the creator is about to ship and wants to know their codebase is safe. | | `email` | `vvibe-email` | ops | Run follower-email invitation campaigns end-to-end — draft a campaign with subject + HTML body (vibe_create_campaign / vibe_update_campaign), dispatch via vibe_send_campaign, read post-send analytics — plus wire up where the email CTA redirects (VVibe-hosted waitlist, self-hosted /waitlist/[slug], or directly into the creator's existing register flow via inviteRedirectPath). Reads the creator's Product Knowledge Base (vibe_get_product_kb) before drafting so campaign copy uses their real brand voice, value prop, and audience and steers clear of forbidden_claims. Add to reach members outside the platform and drive re-engagement. | | `product_brain` | `vvibe-product-brain` | context | Extracts the creator's product into a structured Product Knowledge Base that every other skill (SEO, email, conversion, future social) reads before drafting. Sources: GitHub repo, public website, or document set. Behavior in three layers: EXTRACT verbatim from source first; INFER only when source is ambiguous and tag confidence; never FABRICATE — gaps go into missing_fields so the creator can confirm later. Writes the result via vibe_set_product_kb. Runs in two modes — `build` for first-time setup (no prior Knowledge Base) and `refresh` to diff a new run against the existing Knowledge Base (produces change_log). | | `blog_writer` | `vvibe-blog-writer` | ops | Draft SEO blog articles from the creator's Product Knowledge Base, then publish them to the creator's own VVibe headless blog (target: 'native' — no external CMS, no setup) or as a draft to their WordPress. Reads brand voice, FAQ, audience, and forbidden_claims so articles stay on-brand and legally safe; the server enforces the generation spec (answer-first structure, FAQ, JSON-LD). Add when the creator wants to write / draft / publish / unpublish blog posts. Pairs downstream with vvibe-blog-render to display them. | | `blog_render` | `vvibe-blog-render` | ops | Build the blog frontend in the creator's OWN app that renders their VVibe-published articles from the public content API — index + post pages, the SEO VVibe already generated (meta + JSON-LD), incremental revalidation, plus an RSS feed and sitemap at the creator's own domain. VVibe is a headless CMS — it serves content but renders nothing; this skill is the "head". Read-only (no credentials). Add after publishing to the VVibe blog (vvibe-blog-writer), to actually show the articles on the creator's site. | | `changelog` | `vvibe-changelog` | context | Log product changes after shipping (new feature, pricing change, repositioning, fix) so vvibe knows when the Product Knowledge Base is out of date, and get nudged to announce major shipped features via an email campaign or blog post once they're logged. | The full machine-readable catalog (with versions and rich metadata) is at . ## Common workflows ### A. User asks: "What can vvibe do?" 1. Read this skill (you're reading it now). 2. Call `vibe_list_skills` to see what's available. 3. Summarize back in the user's voice — they are non-technical. Don't dump the catalog raw; ask what they want to accomplish and recommend 1–2 skills. ### B. User asks: "Help me set up " 1. Identify which skill maps to (Payment for monetization, Member for sign-up, Email for transactional mail, Analytics for traffic, Sentry for errors). 2. Install that skill: `npx skills add vvibe/vvibe-skills --skill --yes` 3. Report: `vibe_report_skill_installed` 4. Follow the skill's own `SKILL.md` for the next steps — each skill has its own workflow. ### C. User wants to deploy a vvibe official demo Each official demo lives in its own GitHub repository — one repo per demo, marked as a GitHub Template Repository so end users can click "Use this template" rather than fork. The full catalog is at the `vvibe-demo` topic page: . Each demo has a `.vvibe-demo.yml` file at its root declaring: - Which vvibe skills are pre-installed - Which InsForge template the demo uses - The demo's identity (name, displayName, description) If you find a `.vvibe-demo.yml` in the working directory, treat the repo as an official demo and follow its `README.md` setup section verbatim. The README has been written specifically for end-user flow: InsForge signup → `npx @insforge/cli create` → deploy. ## Partner integrations ### InsForge (hosting) vvibe official demos are deployed on **InsForge** — Postgres, auth, storage, edge functions in one platform. - Referral signup: - Agent setup doc: - CLI: `npx @insforge/cli` When a user is working on a vvibe official demo and asks "how do I deploy this?", route them to the InsForge CLI workflow in the demo's README (don't try to invent a deploy path). ## Hard rules - **Never** commit secrets the user pastes into chat — vvibe access tokens, InsForge admin keys, Stripe secret keys. These all stay in `.env.local` or out of the repo entirely. - **Never** push to the user's remote without their explicit OK. The dashboard treats unscheduled pushes as anomalies. - **Always** report skill installs via `vibe_report_skill_installed`. Silent installs break the dashboard's source-of-truth for what you have. - The user is non-technical. If you need to surface an HTTP status code, Stripe error, or stack trace — wrap it in plain language explaining what failed and what they should do next. ## Reference - Site: - Dashboard: - Skills catalog (machine-readable): - MCP endpoint discovery: - Skills source: - Official demos (GitHub topic index): - InsForge partner: