Ops Deploy Skill for Claude

Deploy status across all projects. Shows ECS service versions, Vercel deployments, recent deploys, pending deploys, and CI/CD pipeline state.

2k tokens

context cost

the whole folder, loaded on every use

files

instructions only

copies elsewhere

how many repositories repackaged it

3248

stars on the repo

on the repository, not the skill itself

Install

one command, takes just this skill from the repository

npx skills add https://github.com/davepoon/buildwithclaude --skill ops-deploy

What it tells the agent to use

found in the instruction text

WebFetch fetches pages from the network

Task spawns other agents

The instruction itself

18 sections, as written by the author

OPS ► DEPLOY STATUS

Runtime Context

Before executing, load available context:

Preferences: Read ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json
timezone — display all deploy timestamps in the correct timezone

Daemon health: Read ${CLAUDE_PLUGIN_DATA_DIR}/daemon-health.json
Check infra-monitor status — if not running, note that ECS data may be stale

Secrets: AWS and Vercel credentials required.

Secret Resolution

AWS: check $AWS_PROFILE / $AWS_ACCESS_KEY_ID → doppler secrets get AWS_ACCESS_KEY_ID --plain → vault query cmd from prefs
Vercel token: check $VERCEL_TOKEN → doppler secrets get VERCEL_TOKEN --plain → vault

CLI/API Reference

aws CLI

| Command | Usage | Output |

|---------|-------|--------|

| aws ecs list-clusters --output json | All ECS clusters | {clusterArns: [...]} |

| aws ecs list-services --cluster <name> --output json | Services in cluster | {serviceArns: [...]} |

| aws ecs describe-services --cluster <name> --services <arn> --output json | Service health | {services: [{serviceName, status, runningCount, desiredCount, pendingCount}]} |

| aws logs tail /ecs/<service> --since 1h --format short | ECS logs | Log lines |

gh CLI (GitHub)

| Command | Usage | Output |

|---------|-------|--------|

| gh run list --repo <owner/repo> --limit 5 --json status,conclusion,name,headBranch,createdAt,databaseId | CI runs | JSON array |

| gh run view <id> --repo <repo> --log-failed | Failed CI logs | Log output |

| gh run watch <run-id> --repo <repo> | Stream CI run | Live output (use with Monitor) |

Agent Teams support

If CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is set, use Agent Teams when checking deploy platforms in parallel. This enables:

Agents share context and can coordinate mid-flight
You can steer priorities in real-time
Agents report progress as they complete

Team setup (only when flag is enabled):

TeamCreate("deploy-team")
Agent(team_name="deploy-team", name="ecs-checker", prompt="List all ECS clusters and describe service health, running/desired counts")
Agent(team_name="deploy-team", name="vercel-checker", prompt="List Vercel projects and recent deployments with status")
Agent(team_name="deploy-team", name="ci-checker", prompt="Check GitHub Actions runs across all registered repos for failures")

If the flag is NOT set, use standard fire-and-forget subagents.

Phase 1 — Gather deploy data in parallel

ECS services (all clusters)

${CLAUDE_PLUGIN_ROOT}/bin/ops-infra 2>/dev/null || \
aws ecs list-clusters --output json 2>/dev/null

ECS service details

for cluster in $(aws ecs list-clusters --output json 2>/dev/null | jq -r '.clusterArns[]'); do
  cluster_name=$(basename "$cluster")
  aws ecs list-services --cluster "$cluster_name" --output json 2>/dev/null | \
    jq -r '.serviceArns[]' | while read svc; do
    aws ecs describe-services --cluster "$cluster_name" --services "$svc" \
      --output json 2>/dev/null | jq '.services[] | {name: .serviceName, desired: .desiredCount, running: .runningCount, pending: .pendingCount, image: (.taskDefinition // "unknown"), status: .status}'
  done
done

Recent GitHub Actions runs (registry-driven)

REGISTRY="${CLAUDE_PLUGIN_ROOT}/scripts/registry.json"
[ -f "$REGISTRY" ] || REGISTRY="${CLAUDE_PLUGIN_ROOT}/scripts/registry.example.json"
for repo in $(jq -r '.projects[] | select(.gsd == true) | .repos[]' "$REGISTRY" 2>/dev/null); do
  echo "=== $repo ==="
  gh run list --repo "$repo" --limit 5 --json status,conclusion,name,headBranch,createdAt,databaseId 2>/dev/null
done

Vercel deployments

Use mcp__claude_ai_Vercel__list_projects then mcp__claude_ai_Vercel__list_deployments for each project (limit 5 per project).

Phase 2 — Render dashboard

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 OPS ► DEPLOY STATUS — [timestamp]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ECS SERVICES
 CLUSTER    SERVICE         D/R/P   STATUS   LAST DEPLOY
 ─────────────────────────────────────────────────────
 [cluster]  [service]       [x/x/x] ACTIVE   [time ago]
 ...

VERCEL DEPLOYMENTS
 PROJECT     ENV        STATUS    COMMIT    DEPLOYED
 ─────────────────────────────────────────────────────
 [project]   production  READY    [sha]     [time ago]
 ...

CI/CD PIPELINE
 REPO              BRANCH   WORKFLOW        STATUS    AGE
 ─────────────────────────────────────────────────────
 example-api       main     Deploy API      ✓ success  2h
 example-web       dev      Build            ✗ failure  1h
 ...

PENDING DEPLOYS (branch ready, not yet deployed)
 [repo] [branch] [PR#] [CI status] → needs merge to trigger

──────────────────────────────────────────────────────

After rendering, use batched AskUserQuestion calls (max 4 options each). Only show actions relevant to the current state (e.g., skip "View logs for failing service" if nothing is failing). If <=4 relevant actions, use a single call. If >4, batch:

AskUserQuestion call 1:

  [View logs for [failing service]]
  [Trigger manual deploy for [project]]
  [View build logs for [failing CI run]]
  [More actions...]

AskUserQuestion call 2 (only if "More actions..."):

  [Check Vercel [project] runtime logs]
  [Open GitHub Actions for [repo]]
  [Back to dashboard]

Deep-dive by project

If $ARGUMENTS has a project alias, show only that project's deploy info + last 10 CI runs + option to view logs.

For failing deploys: offer to view logs via mcp__claude_ai_Vercel__get_deployment_build_logs or ECS CloudWatch logs.

If user selects manual deploy (option b), confirm with AskUserQuestion before triggering:

Trigger deploy for [project]:
  Environment: [production/staging]
  Branch: [branch]
  Last commit: [sha] — [message]

  [Deploy now]  [View diff since last deploy first]  [Cancel]

If user selects to view logs, show the logs and use AskUserQuestion:

  [Dispatch fix agent for this failure]  [Redeploy]  [Back to dashboard]

Native tool usage

Monitor — live deploy streaming

When watching a deploy in progress, use Monitor to stream logs:

Monitor(command: "gh run watch <run-id> --repo <repo>")

For ECS deploys: Monitor(command: "aws ecs wait services-stable --cluster <cluster> --services <service>")

Tasks — deploy tracking

Use TaskCreate per project being deployed. Update with TaskUpdate as deploys succeed/fail.

WebFetch — Vercel fallback

When Vercel MCP tools are unavailable, use WebFetch with the Vercel API directly:

WebFetch(url: "https://api.vercel.com/v6/deployments?projectId=<id>&limit=5", headers: {"Authorization": "Bearer $VERCEL_TOKEN"})

Other skills for the same job

different authors, same section of the catalogue

Azure Kubernetes Automatic Readiness

by microsoft

vendor ×3

Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess cluster for Automatic compatibility, fix deployment for Automatic compatibility, identify AKS Automatic migration blockers, is my cluster ready for AKS Automatic.

Discovers available Azure OpenAI model capacity across regions and projects. Analyzes quota limits, compares availability, and recommends optimal deployment locations based on capacity requirements. USE FOR: find capacity, check quota, where can I deploy, capacity discovery, best region for capacity, multi-project capacity search, quota analysis, model availability, region comparison, check TPM availability. DO NOT USE FOR: actual deployment (hand off to preset or customize after discovery), quota increase requests (direct user to Azure Portal), listing existing deployments.

Interactive guided deployment flow for Azure OpenAI models with full customization control. Step-by-step selection of model version, SKU (GlobalStandard/Standard/ProvisionedManaged), capacity, RAI policy (content filter), and advanced options (dynamic quota, priority processing, spillover). USE FOR: custom deployment, customize model deployment, choose version, select SKU, set capacity, configure content filter, RAI policy, deployment options, detailed deployment, advanced deployment, PTU deployment, provisioned throughput. DO NOT USE FOR: quick deployment to optimal region (use preset).

Unified Azure OpenAI model deployment skill with intelligent intent-based routing. Handles quick preset deployments, fully customized deployments (version/SKU/capacity/RAI policy), and capacity discovery across regions and projects. USE FOR: deploy model, deploy gpt, create deployment, model deployment, deploy openai model, set up model, provision model, find capacity, check model availability, where can I deploy, best region for model, capacity analysis. DO NOT USE FOR: listing existing deployments (use foundry_models_deployments_list MCP tool), deleting deployments, agent creation (use agent/create), project creation (use project/create).

Intelligently deploys Azure OpenAI models to optimal regions by analyzing capacity across all available regions. Automatically checks current region first and shows alternatives if needed. USE FOR: quick deployment, optimal region, best region, automatic region selection, fast setup, multi-region capacity check, high availability deployment, deploy to best location. DO NOT USE FOR: custom SKU selection (use customize), specific version selection (use customize), custom capacity configuration (use customize), PTU deployments (use customize).

This skill should be used when working with LaminDB, an open-source data framework for biology that makes data queryable, traceable, reproducible, and FAIR. Use when managing biological datasets (scRNA-seq, spatial, flow cytometry, etc.), tracking computational workflows, curating and validating data with biological ontologies, building data lakehouses, or ensuring data lineage and reproducibility in biological research. Covers data management, annotation, ontologies (genes, cell types, diseases, tissues), schema validation, integrations with workflow managers (Nextflow, Snakemake) and MLOps platforms (W&B, MLflow), and deployment strategies.

Latch platform for bioinformatics workflows. Build pipelines with Latch SDK, @workflow/@task decorators, deploy serverless workflows, LatchFile/LatchDir, Nextflow/Snakemake integration.

Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.

17k tokens

How to use it

Copy the folder

Take davepoon/ops-deploy from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.