Agent skill · software engineering · jeremylongshore
castai-local-dev-loop
Build an offline-first local loop for CAST AI Terraform, Helm, policy, and workload configuration before touching a sandbox cluster. Use when developing infrastructure modules, annotations, or CI checks. Trigger with: "develop CAST AI locally", "test CAST AI configuration", "make a CAST AI dev loop".
Why this skill is useful
Adds executable scripts for cost monitoring and Terraform integration that enhance local Kubernetes development workflows.
What it needs
Requires helm, kubectl, terraform installed locally. Requires castai account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
CAST AI Offline-First Development Loop Overview Make configuration feedback fast without treating a live cluster as a test fixture. Render, validate, diff, and policy-check locally; use a sandbox only for the behavior that cannot be proven offline. Prerequisites Repository-owned Terraform, Helm values, policy, or workload manifests Pinned tool and provider versions Sanitized fixtures for cluster identity, policies, and API failures Optional sandbox with a distinct kube context and budget owner Instructions Step 1: Map inputs and ownership Use Read and Grep to locate provider constraints, chart versions, values, annotations, policy definitions, generated files, and secret references. Identify which files are authoritative and which are derived. Step 2: Establish local gates Use Bash(terraform:) to format and validate without applying. Use Bash(helm:) to lint and render pinned charts. Use Bash(kubectl:\) only for client-side schema checks against rendered objects. Add deterministic tests for region, organization, policy bounds, automation state, HPA ownership, and prohibited secrets. Step 3: Model negative paths Use Write or Edit to add sanitized fixtures for missing identity, wrong region, permission denial, malformed configuration, conflicting controllers, unavailable metrics, PDB denial, and unsatisfied node constraints. Assert fail-closed behavior. Step 4: Preview sandbox connection When installation behavior must be checked, use Bash(castctl:\) with the documented dry-run against the named sandbox context. Compare detected identity and proposed changes to approved fixtures before any connection. Step 5: Run one bounded sandbox experiment Use a reviewed plan and one disposable workload or policy assignment. Observe only the intended behavior, never production data. Do not use a personal API key or console edits that bypass the repository source of truth. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/castai-local-dev-loop