devopsellence

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

devopsellence

Use this skill when the user wants to deploy an app with devopsellence, check deployment state, manage secrets, register and attach their own nodes, or edit the main lifecycle-hook config.

当用户想要使用devopsellence部署应用、检查部署状态、管理密钥、注册并附加自有节点或编辑主生命周期钩子配置时，可使用此技能。

Default flow

默认流程

Work in the app directory the user wants to deploy.
Check whether the CLI is already available:

command -v devopsellence

If the command is missing, tell the user the devopsellence CLI is required and point them to the official docs. Do not run setup scripts from this skill.

Choose the workspace mode before initializing. First inspect any existing mode/context:

devopsellence mode show || true
devopsellence context show || true

If a mode is already configured, use it. If no mode is configured and the user has not explicitly chosen one, do not default silently. Ask a short mode-selection question, make a recommendation, and wait for confirmation before running

devopsellence init

devopsellence has two workspace modes:
solo
: SSH-first, single-operator, existing or provider-created VMs, local node state, local secrets, direct Docker image streaming over SSH.
shared
: hosted sign-in, org/project/env context, team workflows, shared encrypted secrets, and control-plane-managed nodes.
Based on what you’ve told me, I recommend
<solo|shared>
because
<reason>
. Should I initialize this repo in
<solo|shared>
mode?

Recommend

solo

when the user mentions their own VM/server, SSH, single-operator usage, local secrets, direct image streaming, or avoiding hosted/team workflows.

Recommend

shared

when the user mentions teams, org/project/env context, browser sign-in, hosted control plane, shared encrypted secrets, managed nodes, auditability, or collaboration.

If intent is still ambiguous, ask whether they are deploying SSH-first to their own VM as one operator or want the hosted/team workflow.

Initialize the workspace before the first deploy only after mode confirmation. For solo:

devopsellence init --mode solo

For shared:

devopsellence auth whoami || devopsellence auth login
devopsellence init --mode shared

If the user already knows the shared target workspace values, prefer explicit flags:

devopsellence init --mode shared --org acme --project shop --env staging

Validate local state after initialization and before deploy:

devopsellence doctor

Deploy the app:

devopsellence deploy

In shared mode, if the user wants to deploy an existing image digest instead of building locally:

devopsellence deploy --image docker.io/example/app@sha256:...

Verify the result:

devopsellence status

在用户想要部署的应用目录中操作。
检查CLI是否已可用：

command -v devopsellence

如果该命令不存在，告知用户需要devopsellence CLI，并引导他们查看官方文档。不要通过此技能运行安装脚本。

初始化前选择工作区模式。首先检查现有模式/上下文：

devopsellence mode show || true
devopsellence context show || true

如果已配置模式，则使用该模式。如果未配置模式且用户未明确选择，不要默认选择。提出简短的模式选择问题，给出建议，等待确认后再运行

devopsellence init

：

devopsellence有两种工作区模式：
solo
：优先使用SSH，单操作者模式，支持现有或服务商创建的VM，本地节点状态，本地密钥，通过SSH直接流式传输Docker镜像。
shared
：托管登录，组织/项目/环境上下文，团队协作流程，共享加密密钥，控制平面管理节点。
根据您的描述，我推荐
<solo|shared>
模式，原因是
<理由>
。是否要将此仓库初始化为
<solo|shared>
模式？

当用户提及自有VM/服务器、SSH、单操作者使用、本地密钥、直接镜像流或想要避免托管/团队流程时，推荐

solo

模式。当用户提及团队、组织/项目/环境上下文、浏览器登录、托管控制平面、共享加密密钥、管理节点、可审计性或协作时，推荐

shared

模式。如果意图仍不明确，询问用户是作为单个操作者通过SSH优先部署到自有VM，还是想要托管/团队工作流。

仅在模式确认后，首次部署前初始化工作区。对于solo模式：

devopsellence init --mode solo

对于shared模式：

devopsellence auth whoami || devopsellence auth login
devopsellence init --mode shared

如果用户已知shared目标工作区的值，优先使用明确的参数：

devopsellence init --mode shared --org acme --project shop --env staging

初始化后、部署前验证本地状态：

devopsellence doctor

部署应用：

devopsellence deploy

在shared模式下，如果用户想要部署现有镜像摘要而非本地构建：

devopsellence deploy --image docker.io/example/app@sha256:...

验证结果：

devopsellence status

CLI output contract

CLI输出约定

The devopsellence CLI is agent-primary. Treat stdout as the primary machine-readable contract.

Bounded successful commands emit one JSON document on stdout.
Long-running commands typically emit newline-delimited JSON events on stdout.
Some commands may also emit optional structured progress or diagnostic events on stderr, for example during auth flows. Treat stderr events as supplemental rather than the primary contract, and do not scrape human prose from stderr unless diagnosing a CLI/runtime failure.
On command failure, stdout uses a structured
```
event: "error"
```
envelope with
```
ok: false
```
and
```
error
```
details even for otherwise bounded commands.
Streaming event envelopes always include
```
schema_version
```
; bounded JSON results often include it, but some legacy bounded results may omit it.
When
```
schema_version
```
is present, check it before relying on command-specific fields; if it is missing from a bounded result, be tolerant and treat command-specific fields cautiously.
For schema version 1, streaming events use a common envelope:
- ```
event
```
  :
```
started
```
  ,
```
progress
```
  ,
```
result
```
  , or
```
error
```
- ```
operation
```
  : stable operation name when available
- final success events include
```
ok: true
```
- final failure events include
```
ok: false
```
  and
```
error
```
Structured errors use
```
error.code
```
,
```
error.message
```
, and
```
error.exit_code
```
.
Command-specific fields are top-level. Tolerate unknown fields, but do not assume undocumented fields are stable.
Prefer explaining failures from structured
```
code
```
,
```
message
```
, evidence fields, and suggested next actions when present.
If
```
schema_version
```
is unsupported, do not make high-risk decisions from command-specific fields; summarize the raw structured output and ask for updated docs or skill guidance. If
```
schema_version
```
is missing from a bounded result, treat common fields cautiously and avoid assuming undocumented command-specific fields are stable.
Keep secret values out of logs and chat output.

devopsellence CLI以Agent为核心。将stdout视为主要的机器可读约定。

执行成功的有限命令会在stdout输出一个JSON文档。
长时间运行的命令通常在stdout输出换行分隔的JSON事件。
某些命令可能还会在stderr输出可选的结构化进度或诊断事件，例如在认证流程中。将stderr事件视为补充而非主要约定，除非诊断CLI/运行时故障，否则不要从stderr提取人工可读文本。
命令失败时，即使是有限命令，stdout也会使用结构化的
```
event: "error"
```
信封，包含
```
ok: false
```
和
```
error
```
详情。
流式事件信封始终包含
```
schema_version
```
；有限JSON结果通常包含该字段，但一些旧版有限结果可能会省略。
当存在
```
schema_version
```
时，在依赖命令特定字段前先检查该版本；如果有限结果中缺少该字段，请保持兼容，并谨慎处理命令特定字段。
对于版本1的schema，流式事件使用通用信封：
- ```
event
```
  ：
```
started
```
  、
```
progress
```
  、
```
result
```
  或
```
error
```
- ```
operation
```
  ：可用时为稳定的操作名称
- 最终成功事件包含
```
ok: true
```
- 最终失败事件包含
```
ok: false
```
  和
```
error
```
结构化错误使用
```
error.code
```
、
```
error.message
```
和
```
error.exit_code
```
。
命令特定字段为顶级字段。兼容未知字段，但不要假设未文档化的字段是稳定的。
优先使用结构化的
```
code
```
、
```
message
```
、证据字段以及建议的后续操作来解释失败（如果存在）。
如果
```
schema_version
```
不支持，请不要根据命令特定字段做出高风险决策；总结原始结构化输出，并请求更新文档或技能指导。如果有限结果中缺少
```
schema_version
```
，请谨慎处理常见字段，不要假设未文档化的命令特定字段是稳定的。
不要在日志和聊天输出中泄露密钥值。

Secrets

密钥管理

Prefer stdin over literal secret values in prompts or shell history:

printf '%s' "$VALUE" | devopsellence secret set NAME --service web --stdin
devopsellence secret list --env production
devopsellence secret delete NAME --service web

In solo mode, 1Password references are also supported:

devopsellence secret set NAME --service web --store 1password --op-ref op://vault/item/field

优先使用stdin而非在提示或shell历史中使用明文密钥值：

printf '%s' "$VALUE" | devopsellence secret set NAME --service web --stdin
devopsellence secret list --env production
devopsellence secret delete NAME --service web

在solo模式下，还支持1Password引用：

devopsellence secret set NAME --service web --store 1password --op-ref op://vault/item/field

Bring your own node

自有节点管理

Use these in shared mode for a provider-created node. By default,

node create

registers and attaches the node to the current environment:

devopsellence init --mode shared
printf '%s' "$HCLOUD_TOKEN" | devopsellence provider login hetzner --stdin

在shared模式下，以下命令适用于服务商创建的节点。默认情况下，

node create

会注册节点并将其附加到当前环境：

devopsellence init --mode shared
printf '%s' "$HCLOUD_TOKEN" | devopsellence provider login hetzner --stdin

or: devopsellence provider login hetzner --token "$HCLOUD_TOKEN"

devopsellence node create prod-1 --provider hetzner devopsellence node list devopsellence node detach <id> devopsellence node remove <id>


If you intentionally create an unassigned shared node, attach it later:

```sh
devopsellence node create prod-1 --provider hetzner --unassigned
devopsellence node attach <id>

Use this in shared mode for an existing server that you will install manually:

devopsellence node register

Use these in solo mode when the user wants SSH-first workflows without the control plane on an existing VM:

devopsellence init --mode solo
devopsellence node create prod-1 --host <ip> --user root --ssh-key ~/.ssh/id_ed25519
devopsellence agent install prod-1
devopsellence node attach prod-1
devopsellence doctor
devopsellence deploy

Use these in solo mode for a provider-created node:

devopsellence init --mode solo
printf '%s' "$HCLOUD_TOKEN" | devopsellence provider login hetzner --stdin

devopsellence node create prod-1 --provider hetzner devopsellence node list devopsellence node detach <id> devopsellence node remove <id>


如果有意创建未分配的shared节点，可稍后附加：

```sh
devopsellence node create prod-1 --provider hetzner --unassigned
devopsellence node attach <id>

在shared模式下，以下命令适用于需要手动安装的现有服务器：

devopsellence node register

在solo模式下，当用户想要在现有VM上使用SSH优先工作流而无需控制平面时，使用以下命令：

devopsellence init --mode solo
devopsellence node create prod-1 --host <ip> --user root --ssh-key ~/.ssh/id_ed25519
devopsellence agent install prod-1
devopsellence node attach prod-1
devopsellence doctor
devopsellence deploy

在solo模式下，以下命令适用于服务商创建的节点：

devopsellence init --mode solo
printf '%s' "$HCLOUD_TOKEN" | devopsellence provider login hetzner --stdin

or: devopsellence provider login hetzner --token "$HCLOUD_TOKEN"

devopsellence node create prod-1 --provider hetzner --install --attach devopsellence doctor devopsellence deploy


For solo diagnostics:

```sh
devopsellence status
devopsellence logs --node prod-1 --lines 100
devopsellence node diagnose prod-1
devopsellence node logs prod-1 --lines 100

For solo cleanup:

devopsellence node detach prod-1
devopsellence agent uninstall prod-1 --yes
devopsellence node remove prod-1 --yes

devopsellence node create prod-1 --provider hetzner --install --attach devopsellence doctor devopsellence deploy


solo模式下的诊断命令：

```sh
devopsellence status
devopsellence logs --node prod-1 --lines 100
devopsellence node diagnose prod-1
devopsellence node logs prod-1 --lines 100

solo模式下的清理命令：

devopsellence node detach prod-1
devopsellence agent uninstall prod-1 --yes
devopsellence node remove prod-1 --yes

Lifecycle hooks

生命周期钩子

When the user is editing

devopsellence.yml

, recognize these deploy-time hooks:

```
tasks.release
```
: one-shot task that runs before rollout. Good for migrations. It reuses the configured service image, env, secrets, and volumes.
For per-node prep work, prefer the image entrypoint or boot-time scripts; the config-level
```
init
```
hook is no longer supported.

当用户编辑

devopsellence.yml

时，识别以下部署时钩子：

```
tasks.release
```
：在滚动发布前运行的一次性任务，适用于迁移场景。它会复用已配置的服务镜像、环境变量、密钥和卷。
对于每个节点的准备工作，优先使用镜像入口点或启动时脚本；配置级别的
```
init
```
钩子已不再支持。

Heuristics

启发式规则

Prefer

devopsellence doctor

after init and before

devopsellence deploy

If Docker is missing or not running, surface the problem clearly. In shared mode, switch to
```
devopsellence deploy --image ...
```
when the user already has a pushed image digest.
If the workspace is not a git checkout and the CLI needs git metadata, stop and ask before creating a repo or commit.
Keep secrets out of logs and chat output. Use environment variables plus
```
--stdin
```
.

初始化后、

devopsellence deploy

前优先运行

devopsellence doctor

。

如果Docker缺失或未运行，清晰地指出问题。在shared模式下，当用户已有推送的镜像摘要时，切换到
```
devopsellence deploy --image ...
```
命令。
如果工作区不是git仓库且CLI需要git元数据，停止操作并询问用户是否创建仓库或提交。
不要在日志和聊天输出中泄露密钥。使用环境变量加
```
--stdin
```
。