Cloud Management

Operate AWS, Azure, and GCP from the terminal as the control plane. Use provider CLIs plus terminal-invoked tools such as docker, terraform, pulumi, kubectl, helm, and CI runners. Do not fall back to a portal unless the user explicitly asks for a console workflow.

In command examples below, <skill-dir> means the installed cloud-management skill directory and <repo-root> means the target repository root.

Non-Negotiables

Start read-only. Inspect the repo, current provider scope, existing IaC, and deployed state before proposing writes.
Treat cloud as a set of concerns, not a single logo. Runtime, database, storage, DNS, secrets, and observability may live on different providers.
Use CLI-only execution. Prefer aws, az, and gcloud, plus CLI-driven IaC or deployment tools already present in the repo.
Reuse the existing state manager. Extend Terraform, Bicep, CloudFormation, Pulumi, Helm, or repo-owned deploy scripts instead of creating a parallel path.
Default to the simplest managed service that fits the workload. Favor managed containers, managed databases, and managed queues over VMs or Kubernetes unless the repo already needs lower-level control.
Default to cost-conscious dev sizing unless the user explicitly asks for production-ready HA, multi-region, or higher compliance posture.
Require explicit approval before high-cost, destructive, public-ingress, org-scope, identity-sensitive, or hard-to-reverse changes.
Prefer short-lived credentials, SSO, managed identity, workload identity, or OIDC federation over static keys.
When a command surface is uncertain, inspect --help, provider docs, or existing repo automation before guessing.
Finish the loop: apply, verify, capture outputs, and record rollback posture.
Treat startup migrations and multi-process runtime containers as inherited constraints, not fresh defaults. Prefer one-off migration jobs and one long-running responsibility per service unless the repo already depends on a combined entrypoint.