MyVibe Skills

Publish static HTML, ZIP archive, or directory to MyVibe. Use this skill when user wants to publish web content to MyVibe.

Security Scan

The skill appears to implement the described MyVibe publishing workflow, but its runtime instructions ask the agent to escalate sandbox/network permissions and install/run external npm packages (including global installs and npx), read/write local files (including ~/.myvibe), and spawn processes — actions that increase risk and deserve careful review before installing.

Purpose & Capability

The name/description (publish static HTML/ZIP/dir to MyVibe) matches the included scripts: uploading via TUS, conversion polling, screenshot generation and publishing metadata. Reading git remote, zipping directories, creating screenshots, and uploading are all coherent with the stated purpose.

Instruction Scope

SKILL.md instructs the agent to run network-enabled Bash commands, potentially globally install agent-browser (npm install -g agent-browser), run `npx http-server`, run `agent-browser` (which manages Chromium), run `npm install` for script dependencies, and run git commands. Those steps require filesystem access, process spawning, network access, and installing third‑party software — broader scope than a purely read-only metadata extractor. The instruction to run Bash commands with `sandbox_permissions=require_escalated` is unusual and raises privilege concerns.

Install Mechanism

There is no formal install spec, but package.json and package-lock.json are included and the SKILL.md explicitly tells operators to run `npm install` (or `npm install -g agent-browser`) and uses `npx` to run http-server. This means dependencies will be fetched from the npm registry at runtime (moderate risk). No downloads from suspicious URLs were found, but dynamic installs and npx execution increase attack surface.

Credentials

The skill does not request unrelated environment variables or cloud credentials. It performs reasonable local operations for publishing (reads files, reads git remote, writes publish history to ~/.myvibe, creates /tmp artifacts) and uses an OAuth/authorization flow (getAccessToken) rather than asking for secrets in env vars. Those behaviors are proportional to the publishing task but involve storing state in the user's home directory and using bearer tokens at runtime.

Persistence & Privilege

The skill is not 'always' installed. It does persist publish history to ~/.myvibe/published.yaml and writes /tmp screenshot result files. The runtime instructions may install global binaries (agent-browser) and run npx which can add software to the environment. The SKILL.md request to run commands with elevated sandbox/network permissions is notable and increases the blast radius if granted.

What to consider before installing

This skill generally does what it claims, but it requires running network-enabled commands, installing npm packages (potentially globally), starting local servers, and writing files in your home and /tmp directories. Before installing or invoking it: 1) Review scripts/utils/auth.mjs to see how access tokens are obtained/stored and where tokens are written; 2) Audit package.json/package-lock.json (and the @aigne dependencies) for any packages you don't trust; 3) Avoid granting a broad/elevated sandbox permission unless you run the skill in an isolated environment (VM or disposable container); 4) Be cautious about allowing global installs (agent-browser) and npx runs — prefer installing required dependencies in an isolated environment under your control; 5) If you need only metadata or simple uploads, consider using a narrower tool that doesn't request global installs or elevated sandbox privileges. If you want, I can inspect auth.mjs (not shown fully) and the remaining truncated files for token storage or other sensitive behavior to refine this assessment.

MyVibe Publish

Publish web content (HTML file, ZIP archive, or directory) to MyVibe.

Prerequisites

• Node.js 18 or later
• All script executions in this skill require network access. Always run Bash commands with sandbox_permissions=require_escalated to ensure network permissions are enabled.
• The deployment and screenshot generation may take a few minutes. Use a 10-minute (600000ms) timeout for publish commands.

Usage

/myvibe:myvibe-publish --file ./dist.zip      # Publish ZIP
/myvibe:myvibe-publish --file ./index.html    # Publish HTML
/myvibe:myvibe-publish --dir ./dist           # Publish directory
/myvibe:myvibe-publish --url https://example.com/app  # Import from URL
/myvibe:myvibe-publish --dir ./dist --new     # Force new Vibe
/myvibe:myvibe-publish --dir ./dist --did z2qaXXX    # Update specific Vibe

Options

Option	Alias	Description
--file <path>	-f	Path to HTML file or ZIP archive
--dir <path>	-d	Directory to compress and publish
--url <url>	-u	URL to import and publish
--hub <url>	-h	MyVibe URL (default: https://www.myvibe.so/)
--title <title>	-t	Project title
--desc <desc>		Project description
--visibility <vis>	-v	Visibility: public or private (default: public)
--did <did>		Vibe DID for version update (overrides auto-detection)
--new		Force create new Vibe, ignore publish history

Workflow Overview

1. Detect Project Type → if no build needed, start screenshot in background
2. Build (if needed) → then start screenshot in background
3. Metadata Analysis → extract title, description, tags
4. Confirm Publish → show metadata, get user confirmation
5. Execute Publish → script auto-reads screenshot result
6. Return Result → show publish URL

First tool call - execute in parallel:

• Read: source file or main files in directory
• Bash: git remote get-url origin 2>/dev/null || echo "Not a git repo"
• Bash: node {skill_path}/scripts/utils/fetch-tags.mjs --hub {hub}

---

Step 1: Detect Project Type

Check	Project Type	Next Step
--file with HTML/ZIP	Single File	→ Start screenshot, then Step 3
Has dist/, build/, or out/ with index.html	Pre-built	→ Step 2 (confirm rebuild)
Has package.json with build script, no output	Buildable	→ Step 2 (build first)
Multiple package.json or workspace config	Monorepo	→ Step 2 (select app)
Has index.html at root, no package.json	Static	→ Start screenshot, then Step 3

Start screenshot for non-build projects (run_in_background: true):

For directory source (--dir):

node {skill_path}/scripts/utils/generate-screenshot.mjs --dir {publish_target} --hub {hub}

For single file source (--file):

node {skill_path}/scripts/utils/generate-screenshot.mjs --file {publish_target} --hub {hub}

IMPORTANT: Use --file when the source is a single HTML file, and --dir when it is a directory. The flag must match the source.type in the publish config so that both scripts calculate the same hash for the screenshot result file.

After starting the screenshot background task, use TaskOutput (with block: false) to check the task output before proceeding. If the output contains "agent-browser is not installed" or "Chromium is not installed":

1. Install agent-browser: npm install -g agent-browser && agent-browser install
2. Re-run the screenshot command (same command as above, run_in_background: true)
3. Check again with TaskOutput (block: false) to confirm it's running

This ensures the screenshot can complete successfully in the background while you continue with metadata analysis.

---

Step 2: Build (if needed)

Detect package manager from lock files, build command from package.json scripts.

Use AskUserQuestion to confirm:

• Pre-built: "Rebuild or use existing output?"
• Buildable: "Build before publishing?"
• Monorepo: "Which app to publish?"

After build completes, start screenshot in background (same check as Step 1: use TaskOutput block: false to verify agent-browser is available, install if needed, then retry), then proceed to Step 3.

---

Step 3: Metadata Analysis

Extract title

Priority: <title> → og:title → package.json name → first <h1>

Generate description (50-150 words, story-style)

Cover: Why (motivation) → What (functionality) → Journey (optional)

Sources: conversation history, README.md, source code, package.json, git log

Guidelines:

• Natural, conversational tone
• Focus on value and story, not technical specs
• Avoid generic "A web app built with React"

Extract githubRepo

From git remote or package.json repository field. Convert SSH to HTTPS format.

Match tags

Fetch tags: node {skill_path}/scripts/utils/fetch-tags.mjs --hub {hub}

Tag Type	Match Method
techStackTags	Match package.json dependencies against tag slug
platformTags	From conversation context (Claude Code, Cursor, etc.)
modelTags	From conversation context (Claude 3.5 Sonnet, GPT-4, etc.)
categoryTags	Infer from project (game libs → game, charts → viz)

---

Step 4: Confirm Publish

Display metadata and use AskUserQuestion:

Publishing to MyVibe:
──────────────────────
Title: [value]

Description:
[50-150 word story]

GitHub: [URL or "Not detected"]
Cover Image: [Will be included if ready]

Tags: Tech Stack: [...] | Platform: [...] | Category: [...] | Model: [...]

Options: "Publish" / "Edit details"

---

Step 5: Execute Publish

Check dependencies: If scripts/node_modules missing, run npm install first. The publish script automatically reads the screenshot result file. Execute publish directly:

Pass config via stdin:

node {skill_path}/scripts/publish.mjs --config-stdin <<'EOF'
{
  "source": { "type": "dir", "path": "./dist", "did": "z2qaXXXX" },
  "hub": "https://www.myvibe.so",
  "metadata": {
    "title": "My App",
    "description": "Story description here",
    "visibility": "public",
    "githubRepo": "https://github.com/user/repo",
    "platformTags": [1, 2],
    "techStackTags": [3, 4],
    "categoryTags": [5],
    "modelTags": [6]
  }
}
EOF

• did optional - for explicit version updates
• coverImage auto-read from /tmp/myvibe-screenshot-{hash}.json
• Screenshot result file cleaned up after publish

---

Step 6: Return Result

After publish script completes, check the script output for these messages:

Success Message

Always include the Vibe URL in your response:

Published successfully!
🔗 [URL]

Upgrade Prompt (Important)

The script prints an upgrade prompt when updating an existing Vibe without version history enabled:

📦 Previous version overwritten. Want to keep version history?
   Upgrade to Creator → {hub}/pricing

You MUST include this upgrade information in your response to the user if the script output contains it. This helps free-tier users discover the version history feature.

---

Error Handling

Error	Action
Dependencies missing	Run npm install in scripts directory
401/403 Auth error	Token auto-cleared, re-run to authorize
Build failed	Analyze error, offer fix, or publish source as-is
Screenshot failed	Skip coverImage, proceed without it
agent-browser missing	Run npm install -g agent-browser && agent-browser install
Script execution failed (network/sandbox)	Check if network permissions are enabled. Add sandbox_permissions=require_escalated and retry
Private mode is only available for Creator and Studio users	See "Private Mode Error Handling" below

Private Mode Error Handling

When publishing with visibility: private fails with "Private mode is only available for Creator and Studio users", use AskUserQuestion to let the user choose:

Question: "Private publishing requires a Creator or Studio subscription. How would you like to proceed?"

Option	Label	Description
1	Publish as Public	Your Vibe will be visible to everyone. You can change this later after upgrading.
2	View Upgrade Options	Open the pricing page to explore subscription plans with private publishing.

Actions based on selection:

• Option 1: Re-run publish with visibility: "public", inform user the Vibe is now public
• Option 2: Display the pricing URL {hub}/pricing and stop the publish flow

Notes

• Always analyze content for meaningful title/description - never use directory names
• Confirm with user before publishing
• Default hub: https://www.myvibe.so/
• Tags fetched fresh from API on each publish
• Publish history in ~/.myvibe/published.yaml for auto version updates
• Use --new to force new Vibe instead of updating