Studio

Studio's killer feature is plain-English evals — describe expected behavior in natural language and an AI judge evaluates outputs semantically. No assertion code, no JSON-schema scaffolding, no reaching for a test framework. You write rules like “Output palette ≤ 2 colors” and “No bg-purple-500 gradient”; Studio generates a panel of test cases against the SKILL.md and runs them against your model of choice. Tests are a top-level tab in the Studio chrome — alongside Eval Cases, Eval Runs, and History — so quality is something you ship, not something you defer.

Run the same skill against multiple prompts, configurations, and models side-by-side. Studio renders a benchmark table with per-rule pass rates so regressions surface at a glance. Pinpoint which model gives you the best output for each skill — Opus 4.7 for design taste, Sonnet 4.6 for cost-sensitive backfills, Haiku 4.5 for fast turnaround, or your local Ollama for offline work. The table is the entire compare workflow: pick two configurations, run, read the diff. No copy-paste between tabs.

Studio is model-agnostic by design. Claude Opus 4.7, GPT-5, Gemini 3, Llama, or any model you wire up via OpenRouter or AnyModel — Studio drives them all the same way. Pick your model in the top-bar dropdown and that's the LLM that runs both the generation and the eval-judge. There's no vendor lock-in: switch models on a whim, rerun a benchmark, watch the pass rate change, decide. Author once, evaluate everywhere.

Every byte stays on your laptop. Studio does not phone home, does not require an account, and does not ship a backend you have to trust. Everything — the SKILL.md drafts, the eval results, the test fixtures, the version history — lives in the project folder you ran npx vskill studio in. When you're ready to share, you publish to GitHub explicitly. Until then nothing leaves the machine. Air-gapped review, regulatory contexts, and on-call coding all work with zero special configuration.

One click on Publish. If your skill is a local folder with no remote, Studio runs gh repo create for you, pushes the bundle, and submits the GitHub URL to verified-skill.com. The submission page cycles Queued → Scanning… → Processed ✓ · v1.0.0 as the security pipeline runs (Snyk, Socket, internal scanners). When it lands green you have a published version that consumers can install with the vskill CLI or via Studio's install scope picker. See the security guidelines for the full scan stack.

When a consumer hits Install in Studio, they pick a scope: Project writes to .claude/skills/ in the current folder (the default — contained, reversible); User writes to ~/.claude/skills/ (every project on this machine); Global writes to /usr/local/share/claude/skills/ (every machine and every user — typically used in CI images or shared dev pods). Each scope writes the canonical SKILL.md plus per-agent shims for Cursor, Codex, Windsurf, and Copilot — install once, run everywhere. Scope is a runtime decision, not a build-time one.

When an author publishes a new version, Studio's bell-icon updater lights up — push, not poll. The popup shows the version diff (e.g. 1.0.0 → 1.0.1) with an Update CTA that flips the row to ✓ Updated to 1.0.1 and writes the new SKILL.md to your configured scope in one click. Stay in sync with the author's latest taste without the standard package-manager dance. The background channel is SSE; falls back to polling if SSE is blocked by your network.

• Security guidelines — the security-scan pipeline that gates every published version.
• Plugins — install Studio functionality as Claude Code plugins.
• Submitting skills — manual submission flow for authors not using Studio's Publish action.