cloud-instance-ops

Files (17)

• SKILL.md
• openai.yaml · agents/
• aliyun.md · references/
• aws.md · references/
• generic-linux.md · references/
• install-and-examples.md · references/
• interrupted-run-recovery.md · references/
• model-deployment.md · references/
• restricted-access.md · references/
• shared-runtime-hygiene.md · references/
• artifact_check.py · scripts/
• deployment_final_check.py · scripts/
• normalize_result.py · scripts/
• password_ssh.py · scripts/
• preflight.py · scripts/
• remote_port_owner.py · scripts/
• ssh_probe.py · scripts/

SKILL.md (first lines)

# Cloud Instance Ops

## Overview
Use this skill to manage cloud servers and instances like a careful human operator **within the current authorization boundary**. Prefer SSH and official cloud CLIs. Do **not** try to bypass MFA, SSO, approval workflows, captchas, IP allowlists, bastions, or least-privilege controls.

This skill is optimized for a shared core workflow that can be reused in Codex, OpenClaw, and Claude Code. Codex-specific UI metadata lives in `agents/openai.yaml`; the operational logic stays in this `SKILL.md` plus the bundled references and scripts.

## Use this skill when
- You need to connect to a Linux instance through SSH, password SSH, `ProxyJump`, or a bastion.
- You need file transfer, service/process checks, log inspection, restart operations, or access troubleshooting on an existing instance.
- You need AWS EC2 or Aliyun ECS instance inspection or other cloud-side checks through the official CLI.
- You need to deploy a model, stand up an API, validate output artifacts, or run cloud-side mutating actions **and the user has explicitly asked for that path**.

## Required inputs
Normalize each request into these five inputs before acting:
1. **Target object**: host/IP, instance ID, region, environment, bastion
2. **Cloud environment**: generic Linux, AWS, or Aliyun
3. **Authentication method**: SSH key, password SSH, agent, AWS profile, Aliyun profile, short-lived token, SSO
4. **Restrictions**: MFA, approval, allowlist, no public route, read-only, captcha, missing CLI, shared GPU/port use
5. **Requested action**: connect, transfer, inspect, logs, restart, deploy, single-run, serve, accept, instance-check, cloud-op

Treat `deploy`, `single-run`, `serve`, `accept`, and `cloud-op` as explicit-action modes. Do not enter them from a vague “帮我看看机器” style request without confirming intent from the user prompt or environment.

If an input is missing, infer it from the environment first. Ask the user only for the minimum missing detail.

## Core operating model

### 1. Preflight
Run a lightweight local check before attempting privileged or remote work.

Typical commands:

```bash
python3 scripts/preflight.py --cloud generic --action inspect --host 10.0.0.8 --check-port
python3 scripts/preflight.py --cloud aws --action instance-check --profile prod --region ap-southeast-1
python3 scripts/preflight.py --cloud aliyun --action cloud-op --profile default --region cn-hangzhou
```

Preflight should verify only what is safe to verify locally:
- required binaries exist
- obvious credential sources exist
- referenced files exist
- target port is reachable when requested
- explicit restrictions imply `blocked`, `denied`, or `needs_user`

### 2. Execution
Use the narrowest command that answers the request.
- Prefer read-only checks before mutating actions.
- Prefer official cloud CLI for cloud-level state changes.
- For instance lifecycle operations on EC2/ECS, prefer provider CLI/API over in-guest reboot when cloud state matters.

Useful wrappers:

```bash
python3 scripts/ssh_probe.py --host 10.0.0.8 --user ec2-user --identity-file ~/.ssh/prod.pem
python3 scripts/remote_port_owner.py --port 8080
```

### 3. Restriction handling
If the environment requires human involvement, stop and return a structured handoff instead of guessing.

Common stop conditions:
- MFA / SSO / captcha required
- explicit approval required
- IP allowlist or private-network-only path not yet satisfied
- read-only permission for a mutating action
- missing cloud CLI or profile
- SSH key or bastion path unavailable
- shared port/GPU is still occupied by another workload

### 4. Handoff
Return a stable contract for both success and blocked cases so the result can be reused in later handoff, approval, or postmortem steps.

Minimum success shape:

```json
{
  "status": "ok",
  "action": "inspect",
  "target": "10.0.0.8",
  "evidence": {
    "network": {"10.0.0.8:22": "open"}
  },
  "next_step": "Proceed with the requested read-only inspection."
}
```

When blocked, return a concrete next step instead of guessing.

Expected shape:

```json
{
  "status": "blocked",
  "reason": "Target port 22 is unreachable from the current machine.",
  "next_step": "Connect through the approved bastion or ask for the current IP to be allowlisted.",
  "evidence": {
    "network": {"10.0.0.8:22": "closed"}
  }
}
```

Allowed `status` values:
- `ok`
- `blocked`
- `denied`
- `needs_user`
- `unsupported`

## Model deployment workflow
Use this workflow whenever the task is “部署模型 / 起 API / 做题面验收 / 输出文件检查” instead of plain server ops.

### Principle: single-run before serving
Always verify the underlying model or command **once** before wrapping it in an API. Do not start with service orchestration unless the user explicitly asks for service-first diagnosis.

### Recommended sequence
1. **Read-only preflight**: model path, input path, GPU/CPU, memory, ports, dependency versions, existing services
2. **Single-run check**: run one minimal inference locally or remotely and verify the base pipeline works
3. **Service deployment**: only after single-run succeeds, expose HTTP/API/worker entrypoint

From AgenticAIPlan/AgenticAISkills, MIT.

More from AgenticAIPlan/AgenticAISkills