360 Secure SkillHub
360 安全技能中心

universal-shell-deployer

核心功能:跨Windows、Linux、macOS,本地或远程通过统一工作流,完成Redis、MySQL、MinIO等开发服务的安装、配置、启停、验证等操作。典型场景:本机部署MinIO、远程Ubuntu装PostgreSQL、补全macOS开发环境等。需明确目标节点、服务、操作等输入,输出执行计划、操作结果,并更新config.json记录状态。

hgvgfgvh
hgvgfgvh
热度 35.07
最近更新 2026-05-18 11:47:39
分类:开发依赖:代码执行 / 读写文件应用场景:DevOps / 自动化脚本 / 工作流

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add universal-shell-deployer
Metadata
name
universal-shell-deployer
description
Install, configure, start, stop, and verify local or remote development infrastructure across Windows, Linux, and macOS by executing commands through a unified workflow. Use when the user asks to set up databases, MinIO, ZLMediaKit, Docker, Redis, PostgreSQL, MySQL, Nginx, Node.js, Java, or other developer environments on local machines or remote hosts.

Universal Shell Deployer

Purpose

Use this skill for cross-platform environment setup driven by command execution.

Targets may be:

  • local Windows, Linux, or macOS
  • remote Linux or macOS over SSH
  • remote Windows over PowerShell Remoting or another configured command bridge

This skill is configuration-first. Always read the sibling config.json before planning or executing changes.

Required Inputs

Before executing anything, identify:

  1. target node
  2. target service or recipe
  3. desired action: install, configure, start, stop, restart, status, verify, uninstall
  4. whether elevated privileges are allowed
  5. whether the task is local-only, remote-only, or mixed

If any of these are unclear, ask the user.

Config Contract

Read config.json in the same directory and use it as the single source of truth for:

  • default behavior
  • node definitions
  • recipe preferences
  • execution history
  • current state

Update config.json after meaningful progress so future runs can resume from the last known state.

Execution Workflow

1. Load config

Read config.json and resolve:

  • defaults
  • nodes
  • recipes
  • state

If the requested node does not exist, ask whether to create it before proceeding.

2. Select node

Choose a node by name. Respect the node's:

  • transport
  • os
  • shell
  • workdir
  • packageManager
  • privilege policy

If the node says enabled: false, do not use it without user confirmation.

3. Select recipe

If a named recipe exists, use it as the default implementation.

Prefer the recipe's:

  • install method
  • package names
  • service names
  • ports
  • environment variables
  • health checks

If no recipe exists, build a minimal plan using the node defaults and keep it idempotent.

4. Plan before execution

State the concrete execution plan before changing the system:

  • which node will be used
  • which transport will be used
  • which commands will run
  • what success looks like
  • what state fields will be updated

Break risky changes into small steps.

5. Execute by transport

Local

Run commands directly in the correct shell:

  • Windows: prefer powershell
  • Linux/macOS: prefer bash

SSH

Use ssh and keep commands non-interactive where possible.

Prefer:

  • explicit usernames
  • explicit hostnames
  • idempotent shell commands
  • small batches instead of one giant script

Windows remote

Use the configured command bridge in the node definition. Default to PowerShell Remoting semantics unless the user configured something else.

6. Verify every step

After install or configuration, verify with one or more of:

  • package version
  • service status
  • listening port
  • process existence
  • HTTP health endpoint
  • storage login or test query

Never mark a step complete without a verification signal.

7. Persist state

Write back useful state into config.json, such as:

  • state.lastSelectedNode
  • state.lastRecipe
  • state.lastAction
  • state.lastResults
  • state.installations
  • state.services

Record failures with timestamps and short error summaries.

Cross-Platform Rules

  • Prefer the package manager declared in the node config.
  • Do not assume sudo on Windows.
  • Do not assume systemctl exists on all Linux hosts.
  • Do not assume Homebrew exists on macOS unless config says so.
  • For containers, prefer docker compose when already configured in the node or recipe.
  • For direct binary installs, pin the version only when the user asked for it or the recipe requires it.

Safety Rules

  • Never run destructive commands unless the user explicitly approved them.
  • Never wipe data directories during reinstall unless the user asked for a reset.
  • For database setup, prefer creating dedicated users and data directories.
  • For internet downloads, prefer official release URLs recorded in the recipe or confirmed by the user.
  • Surface privilege escalation clearly before executing privileged commands.

Recommended State Shape

When updating config.json, use these sections consistently:

  • nodes.<node>.connection: stable connection metadata
  • nodes.<node>.overrides: node-specific behavior overrides
  • recipes.<recipe>: reusable install/config templates
  • state.installations.<node>.<service>: install status and version
  • state.services.<node>.<service>: running status and health
  • state.lastResults.<node>: last action summary

Suggested Recipe Coverage

Keep recipes for common environment services:

  • redis
  • postgresql
  • mysql
  • minio
  • zlmediakit
  • docker
  • nginx
  • nodejs
  • python
  • java

Each recipe should define:

  • package names by platform
  • service names by platform
  • default ports
  • install steps
  • configuration targets
  • verification commands

Response Style

When using this skill:

  1. briefly confirm the target node and action
  2. show the planned commands before execution
  3. execute in small validated steps
  4. summarize what changed
  5. mention which config.json fields were updated

Example Requests

  • "在本机 Windows 安装 MinIO 并开机启动"
  • "在远程 Ubuntu 机器安装 PostgreSQL 16"
  • "帮我给 dev-linux-01 安装 ZLMediaKit 并验证 1935 和 8080 端口"
  • "在 macOS 上补齐 Docker、Redis、Node.js 开发环境"
  • "更新 prod-edge-02 上的 MinIO 配置但不要删除数据"