TypingMindTypingMindThe best frontend for AI
Cloudstudio Deploy logo

Cloudstudio Deploy

Community
crane-in-clear-sky
cloudstudio_deploy

Deploy static sites to CloudStudio sandbox workspaces or take published sites offline. This skill should be used when users want to deploy a local build directory (e.g. dist/, build/, out/) to a CloudStudio workspace, preview or publish a static site with a shareable URL, or unpublish an existing deployment.

Overview

Publishercrane-in-clear-sky
RepositoryWorkWit-AI-Agent
Skill namecloudstudio_deploy
Stars
118
Forks
5
Bundled files
Instructions only
Links
Skill sourceRepository
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by crane-in-clear-sky on GitHub. Read the source before you install it.

Installation

Install the Cloudstudio Deploy AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/crane-in-clear-sky/WorkWit-AI-Agent/tree/main/workwit/backend/builtin_skills/cloudstudio_deploy
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/crane-in-clear-sky/WorkWit-AI-Agent.git /tmp/WorkWit-AI-Agent
mkdir -p .claude/skills
cp -r /tmp/WorkWit-AI-Agent/workwit/backend/builtin_skills/cloudstudio_deploy .claude/skills/cloudstudio_deploy
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Cloudstudio Deploy in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Cloudstudio Deploy on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Cloudstudio Deploy is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

⚠️ 环境适配：本技能面向 CloudStudio 云端部署平台，当前系统未接入该平台；若用户需要部署静态站点，说明当前能力边界，不执行 npm/CLI 命令。

CloudStudio Deploy

Deploy local static sites to CloudStudio sandbox workspaces or take published sites offline via the built-in workbuddy_cloudstudio_deploy tool.

When to Use

  • User asks to deploy, preview, or publish a static site / web application
  • User asks to unpublish, take offline, or remove a published static site
  • User has a build output directory (e.g. dist/, build/, out/) and wants a live URL
  • User mentions CloudStudio, sandbox, or cloud preview

Limitations

  • Only pure front-end static sites are supported (HTML/CSS/JS/assets).
  • Server-side rendering (SSR), backend APIs, databases, or runtime dependencies (e.g. Node.js server apps) are NOT supported.
  • If the project requires a backend or SSR, inform the user that only static site deployment is currently supported.

How to Deploy

Use the built-in tool workbuddy_cloudstudio_deploy. It accepts:

  • action (optional) — deploy (default) / unpublish
  • directory (deploy required) — absolute path to the build output directory
  • port (deploy only) — port for the static file server, defaults to 3000
  • entry (optional) — entry HTML file; for unpublish, it can narrow a directory match
  • shareLink (unpublish only) — published share link, preferred for precise targeting

Workflow

When a user asks to deploy a site, follow this workflow in order. Be conservative — only proceed with build/deploy when you have high confidence in the result.

Step 1: Identify the deploy target

Check if the user specified a directory. If yes, verify it looks deployable (has index.html). If it does, skip to Step 4.

If no directory is specified, or the specified directory does not contain index.html, proceed to Step 2.

Step 2: Scan for existing build output

Look in the project root for common front-end build output directories. Only check these whitelisted directories (do NOT recursively scan the entire project):

  • dist/
  • build/
  • out/
  • output/
  • public/
  • .next/out/ (Next.js static export)
  • .output/public/ (Nuxt static)
  • _site/ (Jekyll/11ty)
  • www/
  • docs/

For each found directory, check if it contains index.html. If exactly one candidate is found, use it. If multiple candidates exist, ask the user to choose.

Step 3: Attempt to build (conservative strategy)

If no existing build output is found, check if the project has a buildable front-end:

  1. Check for package.json in the project root. If missing, skip to Step 3c.

  2. Look for a build script. Check package.json for these script names (in order of priority):

    • build
    • build:prod
    • build:production
    • generate (Nuxt)
    • export (Next.js)

    If a build script exists:

    • Check if node_modules/ exists. If not, inform the user that dependencies need to be installed first and ask for confirmation before running npm install (or the appropriate package manager based on lock files).
    • Run the build script (e.g. npm run build).
    • After build completes, re-scan the whitelisted directories from Step 2 for index.html.
    • If a deployable directory is found, proceed to Step 4.
    • If the build fails or produces no static output, report the error to the user and stop.

  3. No package.json or no build script:

    • Check if the project root itself contains index.html (simple static site with no build step).
    • If yes, use the project root as the deploy directory.
    • If no, inform the user: "No deployable static site found. This project may require a build step or may not be a static front-end project."
    • Do NOT attempt to guess or construct build commands. Stop and ask the user for guidance.

Step 4: Deploy

Call the workbuddy_cloudstudio_deploy tool with the identified directory:

Step 5: Report result

The tool returns a JSON with shareLink and verified fields.

  • Present the shareLink as the 分享链接 to the user.
  • Do NOT mention expiration, spaceKey, data plane URL, webIDE URL, or any other internal details.
  • If verified is false, suggest the user wait a few seconds and try the link again.

Important Rules

  • Only show the shareLink to the user, referred to as 分享链接.
  • Do NOT mention expiration, validity period, spaceKey, data plane URL, webIDE URL, or any other internal details to the user.
  • Be conservative in build attempts — only run build commands when there is a clear, standard build script present. Never fabricate or guess build commands.
  • If analysis becomes too complex (e.g. monorepo with unclear structure, unconventional build setup), stop and ask the user for clarification rather than guessing.
  • The tool handles everything internally: workspace creation, file upload, static server setup, and link generation.

Unpublish (Take Offline)

Take a previously deployed site offline via the built-in workbuddy_cloudstudio_deploy tool with action: "unpublish". After unpublishing, the site's 分享链接 stops working. This only cancels the artifact release; it does NOT destroy the sandbox and is reversible by redeploying.

When to Unpublish

  • User asks to 下线 / 取消发布 / 撤下 / 删除 a deployed site, or in English to unpublish / take offline / take down / remove a published app.

How to Unpublish

Use the built-in tool workbuddy_cloudstudio_deploy with action: "unpublish". The targeting parameters are optional; provide the most specific one available:

  • shareLink (optional) — the share link of the deployment to take offline. Preferred, most precise.
  • directory (optional) — absolute path of the directory that was deployed. Used when the share link is unavailable.
  • entry (optional) — entry HTML file name, used with directory for precise matching.

Target resolution priority: shareLink → directory (+ entry) → otherwise the most recent still-published deployment in the current workspace.

Workflow

  1. Determine which deployment to take offline:
    • If the user provided or referenced a share link, pass it as shareLink.
    • Otherwise, if the user points to a project directory, pass it as directory.
    • If the user just says "下线刚才那个 / take the last one offline" without specifics, pass only action: "unpublish" and omit the targeting parameters to fall back to the most recent published deployment.
  2. Call workbuddy_cloudstudio_deploy with action: "unpublish".
  3. Report the result:
    • On success, confirm the site has been taken offline and its 分享链接 no longer works.
    • On failure (e.g. no matching deployment found), tell the user no matching deployment was located and ask them to provide the share link or the deployed directory.

Important Rules

  • Do NOT expose conversationId, spaceKey, or any internal identifiers to the user.
  • If multiple deployments could match and the target is ambiguous, ask the user to confirm (e.g. by share link) rather than guessing.

Frequently asked questions

What does the Cloudstudio Deploy AI skill do?

Deploy static sites to CloudStudio sandbox workspaces or take published sites offline. This skill should be used when users want to deploy a local build directory (e.g. dist/, build/, out/) to a CloudStudio workspace, preview or publish a static site with a shareable URL, or unpublish an existing deployment.

Why use Cloudstudio Deploy on TypingMind?

Because you install it once and use it with any model. Cloudstudio Deploy is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Cloudstudio Deploy in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/crane-in-clear-sky/WorkWit-AI-Agent/tree/main/workwit/backend/builtin_skills/cloudstudio_deploy. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Cloudstudio Deploy?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Cloudstudio Deploy?

As many as you like. As long as a model supports skills, you can use Cloudstudio Deploy with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Cloudstudio Deploy AI skill free?

It is published on GitHub by crane-in-clear-sky. Check the repository for licensing terms. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

Related AI Skills

View all
openclaw logo

Openclaw Testing

openclaw
OrganizationPopular

Choose proportional OpenClaw tests and checks, diagnose failures, and route environment-sensitive or release proof to its owner.

82.2K
391K
2 files
View
mattpocock logo

Wizard

mattpocock
CommunityPopular

Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar…

22.3K
264.4K
2 files
View
affaan-m logo

Deployment Patterns

affaan-m
CommunityPopular

Flujos de trabajo de despliegue, patrones de pipeline CI/CD, contenedorización Docker, health checks, estrategias de rollback y listas de verificación de preparación para producción de aplicaciones…

39.1K
261.1K
Instructions
View
affaan-m logo

Docker Patterns

affaan-m
CommunityPopular

Patrones de Docker y Docker Compose para desarrollo local, seguridad de contenedores, networking, estrategias de volúmenes y orquestación de múltiples servicios.

39.1K
261.1K
Instructions
View

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇