dotfiles/home/.config/opencode/skills/cloud-deploy-cli/SKILL.md

name, description

name

description

cloud-deploy-cli

Use when the user asks to deploy a project, create/manage a cloud deployment, roll back a release, tail production logs, or run a cloud command for Railway, Vercel, AWS, Azure, or Google Cloud. Triggers on keywords like "deploy", "railway up", "vercel deploy", "aws cli", "az ", "gcloud", "ship it", "push to prod", "cloud CLI", "rollback". Installs and drives the cloud provider's CLI so the agent can deploy on its own.

Cloud deployment CLIs — let the agent deploy on its own

The agent should run the deploy command itself, not hand the user a link to a web console. Pick the CLI for the user's cloud and run it.

Pick the CLI by what the user named

Cloud	CLI binary	Install (macOS)	Install (other)
Railway	railway	brew install railway / npm i -g @railway/cli	sh -c "$(curl -fsSL cli.railway.app/install.sh)"
Vercel	vercel	npm i -g vercel	same
AWS	aws	brew install awscli	pip install awscli / winget install Amazon.AWSCLI
Azure	az	brew install azure-cli	winget install Microsoft.AzureCLI / curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
Google Cloud	gcloud	brew install --cask google-cloud-sdk	winget install Google.CloudSDK / install from cloud.google.com/sdk

If the user said "deploy" without naming a cloud, ask which one (use the question tool) — or infer from repo files: vercel.json → Vercel, railway.toml/Railway.json → Railway, appspec.yml/.ebextensions → AWS, azure-pipelines.yml/appservice → Azure, app.yaml/Dockerfile+GCP files → GCP.

Verify install: <cli> --version. If missing, install it (table above) then continue.

Authenticate (one-time per CLI)

railway login            # browser login
vercel login             # browser login (vercel link on first deploy in a repo)
aws configure            # prompts for Access Key ID, Secret, region, output
az login                 # browser login
gcloud auth login        # browser login; then gcloud config set project <PROJECT_ID>

For headless/agent runs use env vars instead of interactive login:

CLI	Env vars
Railway	RAILWAY_TOKEN (from Railway dashboard → Settings → API Tokens)
Vercel	VERCEL_TOKEN (or VERCEL_ORG_ID + VERCEL_PROJECT_ID after vercel link)
AWS	AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION (or AWS_PROFILE)
Azure	az login --service-principal -u <app-id> -p <cert/password> --tenant <tenant>
Google	gcloud auth activate-service-account --key-file=<sa.json> then GOOGLE_APPLICATION_CREDENTIALS=<sa.json>

Railway

railway link             # bind cwd to a Railway project/service
railway up               # deploy current directory (detected buildpack or Dockerfile)
railway up --service api # deploy to a specific service
railway status           # current deployment, URL
railway logs             # tail live logs
railway variables        # view env vars (railway variables set KEY=val to add)
railway rollback         # revert to the previous deployment

Vercel

vercel link              # bind repo (writes .vercel/ with org + project IDs)
vercel                   # preview deploy; prints a *.vercel.app URL
vercel --prod            # production deploy (uses production domain)
vercel logs <url>        # tail function/build logs
vercel env ls            # vercel env add KEY (then vercel --prod to redeploy)
vercel rm <url>          # remove a deployment
vercel inspect <url>     # build/runtime details

For a fully scripted agent deploy:

vercel --prod --yes --token "$VERCEL_TOKEN"
# --yes skips all prompts; requires .vercel/ linked (vercel link --yes --token $TOKEN)

AWS

AWS is broad — only use it when the user names a specific AWS service. Common agent tasks:

# S3
aws s3 sync ./dist s3://<bucket>/ --delete
aws s3 presign s3://<bucket>/file.zip --expires-in 3600

# Lambda
aws lambda update-function-code --function-name <fn> --zip-file fileb://fn.zip
aws lambda invoke --function-name <fn> --payload fileb://event.json out.json

# ECS
aws ecs update-service --cluster <c> --service <s> --force-new-deployment
aws ecs describe-services --cluster <c> --services <s>

# Logs (CloudWatch Logs)
aws logs tail /aws/lambda/<fn> --follow
aws logs get-log-events --log-group-name <g> --log-stream-name <s>

# Elastic Beanstalk
eb deploy               # needs `eb` CLI (brew install aws-elasticbeanstalk)

Always pass --region <region> or rely on aws configure's default. For --query/--output text|json to get parseable results.

Azure

az group list -o table
az webapp up --runtime "NODE:20-lts" --sku F1 -n <app> -g <group>      # one-shot deploy from cwd
az webapp deployment source config --name <app> -g <group> --repo-url <git> --branch main
az webapp log tail -n <app> -g <group>
az webapp config appsettings set -n <app> -g <group> --settings KEY=val
az functionapp deployment source config-zip -g <group> -n <fn> --src ./deploy.zip

-o table|json|tsv controls output; --query for JMESPath filtering.

Google Cloud

gcloud config set project <PROJECT_ID>
gcloud app deploy                              # App Engine
gcloud run deploy <svc> --source . --region <r> --allow-unauthenticated   # Cloud Run
gcloud run services list
gcloud run services describe <svc> --region <r>
gcloud functions deploy <fn> --runtime nodejs20 --trigger-http --allow-unauthenticated
gcloud app logs tail -s default
gcloud builds submit --tag gcr.io/<proj>/<img>

When to use

• "Deploy this" / "ship to prod" / "push to staging" with a cloud named or inferable from repo files
• "Roll back the last deploy" / "tail the logs" / "restart the service"
• "Set env var KEY=val on the deployed app" then redeploy
• Any cloud CLI operation where the agent would otherwise say "go to the dashboard"

When NOT to use

• Just running the app locally → use the project's dev server, not a cloud deploy
• Building a Docker image for local use → docker build; only deploy to cloud if the user asks
• Provisioning infra from scratch (VPCs, databases, IAM) → confirm scope first; these CLIs can do it but the user should explicitly ask before the agent creates billable resources

Gotchas

• Always confirm the environment (production vs preview/staging) before --prod/production deploys. Prefer a preview deploy first; ask before promoting.
• vercel without --prod is a safe preview; vercel --prod hits the real domain.
• Railway/Vercel deploys read the repo's build config — check package.json scripts / Dockerfile / vercel.json / railway.toml before deploying so the agent knows what will run.
• AWS/Azure/GCP commands can create billable resources; only run provisioning when the user explicitly asked for it.

Source

Referenced in https://x.com/heyshruti7/status/2069083108092350823 — "Your cloud's CLI — every cloud ships one so your agent can deploy on its own: Railway, Vercel, AWS, Azure, Google Cloud."