CAST AI CI Contract Lane

Overview

Keep pull-request checks local and credential-free. Validate syntax, rendered Kubernetes objects, policy invariants, and destructive change boundaries before allowing a separately protected job to inspect a real CAST AI environment.

Prerequisites

• The workflow, Terraform, Helm values, and workload manifest paths in scope
• An explicit source of truth for each CAST AI setting
• Maintainer approval for any protected live probe

Instructions

Step 1: Map the trust boundary

Use Read and Grep to identify fork execution, secret references, Terraform backends, generated plans, Helm values, kubeconfig use, and direct CAST AI calls. Classify each check as offline, protected read-only, or prohibited.

Step 2: Build the required offline lane

Use Bash(terraform:) for formatting, initialization without applying, validation, and a saved plan. Use Bash(helm:) to lint or template the pinned chart and Bash(kubectl:\*) only for client-side schema validation against rendered manifests. Treat unexpected resource deletion, provider replacement, cluster disconnect, automation enablement, or HPA ownership transfer as review-blocking changes.

Step 3: Validate CAST AI policy invariants

Use Write or Edit to add deterministic checks for approved regions, cluster identifiers, policy names, node-template bounds, workload automation modes, protected namespaces, disruption budgets, and maximum CPU limits. Reject deprecated cluster minimum CPU settings and unreviewed wildcard scope.

Step 4: Isolate the optional live lane

If live evidence is required, place it in an independent protected-environment job that cannot run for forks. Use a dedicated read-only organization-scoped identity, a pinned CAST AI region, a fixed cluster allowlist, a short timeout, and redacted output. Prefer a documented status read; never enable automation or apply infrastructure from the probe.

Step 5: Prove negative behavior

Run the workflow with missing and sentinel credentials. Confirm the offline lane stays green, the live lane skips safely, logs contain no key or raw cluster inventory, and plan artifacts have restricted retention.

Tool Discipline

Use Read and Grep for workflow and configuration inspection. Use Write and Edit for checks and workflow changes. Use Bash(terraform:), Bash(helm:), Bash(kubectl:), and Bash(castctl:) only for their documented validation or dry-run operations; do not apply, connect, disconnect, or mutate a live cluster without a separate approved change window.

Output

• A required credential-free validation job
• A separately protected read-only smoke test, if justified
• Policy, deletion, and secret-handling assertions
• Negative-path and redaction receipts

Examples

A pull request rend…

CAST AI Failure Triage

Overview

Separate observation, connectivity, policy, capacity, and disruption failures before proposing a change. Preserve the failing state, use current component topology, and stop when the evidence requires cloud-provider or CAST AI support access.

Prerequisites

• The exact kube context, cluster, region, time window, and observed symptom
• Read-only access to the castai-agent namespace
• The declared installation owner: castctl, Terraform, GitOps, or console

Instructions

Step 1: Freeze the symptom

Record expected versus actual behavior, timestamps, workload identity, pending-pod reason, and recent configuration changes. Use Read and Grep on runbooks and IaC to determine whether Cost Monitoring, Node Autoscaling, or Workload Autoscaling is actually enabled.

Step 2: Check installation health

Use Bash(castctl:) for version or non-mutating status commands supported by the installed client. Use Bash(helm:) to inspect releases and values, then Bash(kubectl:\*) to inspect workloads, readiness, events, and bounded logs in castai-agent. Do not restart components before collecting evidence.

Step 3: Classify the failure plane

Step 4: Test one hypothesis

Choose the smallest reversible check. Confirm regional endpoint alignment, effective scaling-policy assignment, metrics availability, supported workload type, node-template constraints, and cloud quota. Treat the deprecated cluster minimum CPU setting as migration debt, not a current control to add.

Step 5: Decide the owner and remedy

Map the evidence to the owning layer. Change repository-managed values only through their source of truth; do not mix console edits into Terraform or GitOps ownership. Escalate with a redacted bundle when the failure is inside the hosted control plane or an undocumented provider response.

Tool Discipline

Use Read and Grep for configuration and runbook evidence. Use Bash(kubectl:), Bash(helm:), and Bash(castctl:\*) only for bounded ins…

CAST AI Observation-First Onboarding

Overview

Connect one approved cluster with the recommended castctl path, keep optimization automation off initially, and prove identity, telemetry, ownership, and rollback before expanding control.

Prerequisites

• A named kube context for EKS, GKE, AKS, or a supported CAST AI Anywhere environment
• Cluster-admin access for installation and reviewed least-privilege cloud permissions
• metrics-server when Workload Autoscaling will be evaluated
• An owner, maintenance window, rollback decision, and evidence location

Instructions

Step 1: Establish ownership

Use Read and Grep to locate existing CAST AI, autoscaler, Terraform, Helm, and GitOps definitions. Stop if another controller owns node provisioning or workload HPA behavior and no coexistence decision exists.

Step 2: Preview the connection

Use Bash(castctl:\*) to verify the installed client, authenticate interactively to the intended organization, and run the documented connection dry-run. Record detected provider, cluster, region, selected features, namespace, and proposed cloud changes without connecting.

Step 3: Review permissions and features

Confirm least-privilege cloud access and the exact cluster context. Cost Monitoring is always enabled; select Node Autoscaling or Workload Autoscaling only when entitlement, metrics, disruption, and ownership prerequisites are met. Use Write or Edit to capture the approved choices in the repository runbook.

Step 4: Connect the cluster

Run the reviewed castctl connection during the approved window. Do not substitute the deprecated script flow for a supported castctl environment. Preserve the console URL and sanitized command receipt, never browser tokens or API keys.

Step 5: Verify observation mode

Use Bash(kubectl:\*) to verify namespace workloads, readiness, events, and metrics prerequisites. Confirm the console receives the intended cluster and cost data while automation remains in the approved state. Allow sufficient data before judging savings or recommendations.

Step 6: Hand off automation separately

Document baseline time, current controllers, policy candidates, protected workloads, and rollback owner. Make automation enablement a separate reviewed change using castai-core-workflow-b.

Tool Discipline

Use Read and Grep to establish source-of-truth ownership. Use Write and Edit for the onboarding record and runbook. Use Bash(castctl:) for documented auth, dry-run, connection, and status operations; use Bash(kubectl:) for bounded verification. Never echo credentials or infer permission scope.

Output

• Reviewed dry-run and permission inventory
• One connected cluster with documented feature state
• Agent and telemetry health evidence
• Baseline and automati…

CAST AI Controlled Optimization Rollout

Overview

Turn recommendations into automation one bounded control at a time. Separate node capacity, vertical workload rightsizing, and horizontal replica control so each has an observable success condition and rollback.

Prerequisites

• A healthy connected cluster and representative cost/workload baseline
• Current scaling policies, node templates, PDBs, HPAs, quotas, and protected namespaces
• A low-risk canary workload with an accountable owner

Instructions

Step 1: Define the control matrix

Use Read and Grep to map Node Autoscaling, Workload Autoscaler vertical mode, horizontal autoscaling, existing HPAs, and external provisioners. Record one owner for each control. Do not transfer HPA ownership implicitly.

Step 2: Set guardrails

Use Write or Edit to define approved node templates, availability zones, instance lifecycle constraints, maximum CPU, workload minimums/maximums, policy assignment, PDB expectations, and rollback thresholds. Do not add the deprecated cluster minimum CPU setting.

Step 3: Preview the change

Use Bash(terraform:) to produce a saved reviewed plan when Terraform owns the configuration. Use Bash(castctl:) only for supported inspection or documented feature operations. Confirm the diff affects the intended cluster and canary only.

Step 4: Enable a workload canary

Choose Immediate mode only when controlled pod replacement is acceptable; the Eviction API will enforce PDBs. Choose Deferred mode when recommendations should apply on natural recreation. If horizontal autoscaling is enabled, review the native autoscaling/v2 HPA configuration and any take-ownership decision.

Step 5: Observe capacity and workload outcomes

Use Bash(kubectl:\*) to inspect pending pods, scheduling events, HPA state, pod replacements, PDBs, requests, and node changes. Compare availability, latency, saturation, and spend to the pre-change baseline; do not optimize on cost alone.

Step 6: Expand or roll back

Expand one policy assignment group at a time only after the canary window passes. Roll back automation or policy assignment when error budget, capacity, disruption, or performance thresholds fail, while preserving evidence.

Tool Discipline

Use Read and Grep for ownership and policy evidence. Use Write and Edit for the control matrix and rollback record. Use Bash(terraform:), Bash(castctl:), and Bash(kubectl:\*) only inside the approved plan, rollout, and observation boundaries.

Output

• Node/workload/HPA ownership matrix
• Guardrails and canary selection
• Before-and-after availability, capacity, and cost evidence
• Expansion decision or tested rollback receipt

Examples

A stateless deployment starts in Deferred vertical mode with no HPA o…

CAST AI Cost Evidence Review

Overview

Turn reporting into a prioritized plan without treating modeled savings as invoices. Separate actual spend, available opportunity, realized savings, workload rightsizing, adoption, pricing, and baseline assumptions.

Prerequisites

• The organization and cluster reports for a declared time range
• Cloud billing or internal allocation evidence for reconciliation
• Current automation adoption, workload SLOs, and pricing-adjustment ownership

Instructions

Step 1: Normalize the question

Use Read to identify whether the request concerns actual spend, a forecast, available savings, realized savings, or workload autoscaler savings. Record cluster scope, currency, time range, and comparison period.

Step 2: Validate the reporting basis

Use Grep across exported reports and runbooks to find baseline source, public versus adjusted prices, data gaps, and adoption thresholds. Cost comparison needs sufficient history; new clusters and low automation adoption can legitimately show incomplete or zero savings.

Step 3: Reconcile cost layers

Compare provisioned resources, requested resources, utilization, lifecycle mix, price per resource, actual cost, and modeled baseline. When private discounts or commitments matter, require reviewed Price adjustments instead of assuming public list prices match the bill.

Step 4: Rank opportunities by constraint

Group opportunities into workload rightsizing, node bin-packing, spot or fallback strategy, architecture choice, idle capacity, and allocation hygiene. For each, include savings confidence, SLO risk, prerequisite, owner, and evidence window.

Step 5: Design a measured experiment

Use Write or Edit to create a canary hypothesis with a single policy change, expected capacity effect, performance guardrail, measurement window, and rollback. Do not combine node, vertical, horizontal, and pricing changes in one experiment.

Step 6: Produce the decision record

State what CAST AI reports, what billing evidence confirms, what remains modeled, and which action is authorized. Preserve before-and-after snapshots without exporting sensitive workload names beyond their approved audience.

Tool Discipline

Use Read for reports, billing extracts, and policy context. Use Grep to reconcile repeated cluster, workload, baseline, and pricing facts. Use Write and Edit only for the analysis, experiment, and decision record; this skill does not enable automation.

Output

• Scope and reporting-basis statement
• Reconciled spend and savings table
• Ranked opportunities with confidence and risk
• One controlled experiment and rollback threshold

Examples

A report shows high available savings but no realized savings because the cluster remains read-only. Another cluster shows…

CAST AI Redacted Diagnostic Bundle

Overview

Capture enough evidence to reproduce a CAST AI failure without exporting credentials, Secret payloads, broad cluster inventory, application data, or unbounded logs.

Prerequisites

• Exact kube context, cluster identifier, CAST AI region, incident window, and symptom
• Approved local destination with retention and audience
• Redaction rules for names, labels, annotations, IPs, account data, and credentials

Instructions

Step 1: Declare the bundle contract

Use Write to record incident ID, collector, start and end time, selected namespaces, commands, excluded data classes, redaction method, checksum method, retention, and recipients.

Step 2: Inventory component versions

Use Bash(castctl:) for version information, Bash(helm:) for release metadata and redacted values, and Bash(kubectl:\*) for component images and readiness. Do not collect Helm secrets, rendered Secret objects, service-account tokens, or kubeconfig contents.

Step 3: Capture bounded health evidence

Collect status, restart counts, recent warning events, selected resource descriptions, and logs constrained by component, time, and line count. Include metrics-server status when workload recommendations are involved and pending-pod reasons when node capacity is involved.

Step 4: Capture declared policy context

Use Read and Grep on repository-owned Terraform, Helm values, annotations, node templates, PDBs, and HPAs. Record source paths and commit identifiers. Prefer diffs and normalized summaries over raw state files.

Step 5: Redact and verify

Scan the bundle for API keys, authorization headers, tokens, Secret data, cloud account identifiers, email addresses, private endpoints, and application payloads. Replace values consistently so relationships remain debuggable.

Step 6: Seal the handoff

Write a manifest of included files, omitted evidence, timestamps, tool versions, hashes, and known gaps. Open the sanitized files before sharing and require a second-person review for external support transfer.

Tool Discipline

Use Read and Grep for source and redaction review. Use Write only for sanitized bundle artifacts and the manifest. Use Bash(kubectl:), Bash(helm:), and Bash(castctl:\*) for non-mutating, bounded inspection; never request Secret contents or stream logs indefinitely.

Output

• Sanitized component and cluster-health evidence
• Policy/source-of-truth references
• Redaction report and file manifest
• Checksums, retention, audience, and escalation question

Examples

A workload-autoscaler incident includes component versions, a 15-minute warning-event window, PDB status, policy name, and sanitized logs. It excludes Secret objects, all-namespace inventory, Terraform state, and unrelated …

CAST AI Deployment Integration

Overview

Make the repository the declared source of truth for CAST AI installation and policy, then promote one cluster ring at a time. Keep registration, cloud permissions, chart configuration, and automation decisions independently reviewable.

Prerequisites

• Target clusters grouped into canary, staging, and production rings
• A chosen owner: Terraform, GitOps Helm, castctl, or console
• Pinned provider, module, chart, and policy inputs
• Secret delivery that does not commit or render credentials into artifacts

Instructions

Step 1: Inventory existing ownership

Use Read and Grep to find CAST AI resources, individual component charts, the unified castai chart, Terraform state addresses, Flux or Argo CD objects, and console-only settings. Stop if two systems can reconcile the same resource.

Step 2: Define the repository contract

Use Write or Edit to separate cluster registration, cloud IAM, Helm values, scaling policies, node templates, workload annotations, notification settings, and automation toggles. Parameterize organization, region, and cluster identity; never parameterize a secret with a committed literal.

Step 3: Render and plan

Use Bash(helm:) to lint and render the pinned chart. Use Bash(terraform:) to format, validate, and save a plan. Use Bash(kubectl:\*) for client-side manifest checks. Review RBAC, webhooks, CRDs, namespace, disruption behavior, deleted resources, and ownership transfers.

Step 4: Handle existing installations

If the cluster uses individual CAST AI Helm releases, evaluate the documented castctl cluster migrate path to the unified umbrella chart. Use Bash(castctl:\*) only after recording current releases, values, rollback, and the exact cluster context.

Step 5: Promote by ring

Apply through the declared delivery controller to one canary cluster. Verify agent health, telemetry, policy state, and automation boundaries before staging and production. Require an explicit approval between rings and preserve the reviewed artifact digest.

Step 6: Prove rollback and drift detection

Document how to revert the Git commit or Terraform change, restore policy assignments, and detect console drift. A rollback must preserve cluster connectivity and workload availability; do not assume uninstalling is harmless.

Tool Discipline

Use Read and Grep for ownership discovery. Use Write and Edit for infrastructure definitions and runbooks. Use Bash(helm:), Bash(terraform:), and Bash(kubectl:) for bounded render, plan, and verification. Use Bash(castctl:) only for documented migration or connection actions inside an approved window.

Output

• Source-of-truth and ownership map
• Pinned rendered and planned artifacts
• Ring promotion …

CAST AI Safe First Connection

Overview

Prove the minimum useful loop: identify one sandbox cluster, preview the connection, connect with Cost Monitoring, verify telemetry, and leave optimization automation unchanged.

Prerequisites

• A disposable or non-production kube context with an accountable owner
• castctl installed from an official distribution and authenticated to the intended organization
• Cluster-admin and reviewed provider permissions
• An approved evidence and cleanup plan

Instructions

Step 1: Confirm the sandbox

Use Bash(kubectl:\*) to print the current context and inspect only basic cluster identity. Use Read and Grep to ensure the cluster is not already owned by CAST AI, another autoscaler, Terraform, or GitOps.

Step 2: Preview with castctl

Use Bash(castctl:\*) to check the client version and run the documented cluster connection dry-run. Review detected provider, cluster name, region, organization, proposed features, namespace, and cloud changes.

Step 3: Record the decision

Use Write to capture the dry-run, selected cluster, owners, features, start time, expected telemetry, and cleanup path. Cost Monitoring is always enabled; do not select Node or Workload Autoscaling merely to complete a quickstart.

Step 4: Connect once

Run the reviewed interactive connection. Confirm the prompt resolves the same cluster and organization. Keep the returned console URL, but never store the browser token, kubeconfig, or API key in the receipt.

Step 5: Verify the loop

Use Bash(kubectl:\*) to verify castai-agent namespace workloads, readiness, and recent warning events. Confirm the console identifies the correct cluster and begins showing cost data. Treat an empty initial report as ingestion time, not proof of zero cost.

Step 6: Close or hand off

If the evaluation continues, hand off to observation-first onboarding. If it ends, use the documented disconnect path only after reviewing cloud and cluster cleanup effects and preserving the final receipt.

Tool Discipline

Use Read and Grep for ownership checks. Use Write for the sanitized quickstart receipt. Use Bash(castctl:) for documented dry-run, connection, and status operations and Bash(kubectl:) for bounded verification only.

Output

• Reviewed connection preview
• One correctly identified sandbox cluster
• Agent and initial telemetry evidence
• Explicit continuation or cleanup owner

Examples

A team connects a sandbox EKS cluster for Cost Monitoring, confirms agent readiness, and waits for representative data. It does not enable node automation or change workload requests during the first session.

Error Handling

CAST AI Authentication Boundary

Overview

Keep human castctl login, service API keys, enterprise organization targeting, and cluster installation secrets separate. Choose the narrowest identity for one client, region, organization, and lifecycle.

Prerequisites

• The intended client: castctl, REST, Terraform, CI, or another approved integration
• CAST AI organization, role binding, and environment region
• An approved secret manager, rotation owner, and expiration or review date

Instructions

Step 1: Classify the actor

Use Read and Grep to find existing CAST AI environment variables, provider configuration, CI secrets, Helm values, and runbooks. Distinguish a human interactive session from non-interactive automation; do not reuse one credential across both.

Step 2: Select the authentication path

For human cluster connection, use Bash(castctl:\*) with browser login; castctl stores its own local token and organization selection. For REST or Terraform automation, create an API access key whose inherited role bindings match the required operations.

Step 3: Pin region and organization

Use the documented US, EU, or India API base that matches the CAST AI environment. Send API keys only in the X-API-Key header. For an enterprise key targeting a child organization, also provide X-CastAI-Organization-Id; never infer that identifier from a cluster name.

Step 4: Store without exposure

Use Write or Edit to add secret references, not values, to configuration. Keep keys out of Git, command history, URLs, Terraform outputs, plan artifacts, Helm-rendered output, logs, and support bundles.

Step 5: Verify minimally

Use Bash(curl:\*) only against a documented read endpoint selected from the current CAST AI API specification. Limit output to status and a non-sensitive identifier, set a timeout, and test the expected 401 or 403 path with no credential.

Step 6: Record lifecycle

Document owner, client, role basis, organization, region, storage location, creation time, review date, rotation procedure, and revocation condition. Because a created key cannot be viewed again, loss requires replacement rather than recovery.

Tool Discipline

Use Read and Grep for credential-reference discovery. Use Write and Edit only for secret references and lifecycle documentation. Use Bash(castctl:) for documented interactive auth and Bash(curl:) for a bounded read-only verification; never print headers or key values.

Output

• Actor/client authentication decision
• Region and organization boundary
• Secret-reference configuration
• Minimal verification and rotation record

Examples

A developer uses castctl browser login for a reviewed sandbox connection. A CI job uses a separate organization-scoped read-only API…

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.

Step 6: Capture reproducibility

Record commit, tool versions, rendered artifact hashes, plan summary, sandbox context, start/end time, cleanup, and remaining untested behavior. Return the sandbox to its declared baseline.

Tool Discipline

Use Read and Grep for source discovery. Use Write and Edit for fixtures and checks. Use Bash(terraform:), Bash(helm:), and Bash(kubectl:) for offline validation; use Bash(castctl:) only for a documented dry-run or approved sandbox action.

Output

• Reproducible local validation commands
• Sanitized success and failure fixtures
• Rendered and planned artifact receipts
• Optional bounded sandbox result and cleanup evidence

Examples

A policy change is tested against fixture assertions and a rendered workload annotation before one Deferred-mode sandbox canary. Production cred…

CAST AI Performance Guardrail Tuning

Overview

Tune from evidence across workload demand, requests, replicas, scheduling, and nodes. Keep vertical, horizontal, and node changes separate so a lower bill never hides degraded service.

Prerequisites

• Workload SLOs, error budget, traffic profile, and representative observation window
• Effective scaling policy, annotations, HPA, PDB, node templates, and cluster limits
• Metrics-server and healthy CAST AI components

Instructions

Step 1: Build the timeline

Use Read and Grep to align request rate, latency, errors, pod requests, replicas, pending time, evictions, node provisioning, and policy changes. Identify whether the symptom precedes or follows CAST AI action.

Step 2: Inspect effective workload policy

Check policy assignment, recommendation percentile, overhead, optimization threshold, minimum and maximum resources, confidence, and automation state. Invalid annotation YAML is ignored; an invalid policy name can fall back to a system policy, so verify effective state rather than intended text.

Step 3: Choose application mode

Use Immediate mode only when evictions are acceptable and PDB behavior is proven. Use Deferred mode when recommendations should apply at natural recreation. Account for recommendation confidence and gradual behavior on newly onboarded clusters.

Step 4: Reconcile horizontal scaling

Inspect the native autoscaling/v2 HPA, metric targets, replica bounds, stabilization, and ownership. Avoid competing HPA controllers. When CAST AI takes ownership, treat that as a configuration migration with explicit rollback.

Step 5: Reconcile node capacity

Use Bash(kubectl:\*) to examine pending reasons, affinities, topology, taints, resource shape, and scheduling events. Review node templates and maximum CPU limits. More permissive capacity is not automatically safer or cheaper.

Step 6: Change one variable

Use Write or Edit to record one hypothesis, one configuration change, performance and cost guardrails, observation window, and rollback. Compare the same traffic class and retain SLO evidence before expanding.

Tool Discipline

Use Read and Grep for metrics, policy, and configuration evidence. Use Write and Edit for the tuning experiment and decision. Use Bash(kubectl:\*) for bounded, non-secret inspection of workloads, HPAs, PDBs, events, and nodes.

Output

• Joined performance and scaling timeline
• Effective vertical, horizontal, and node control map
• One-variable experiment with SLO and cost guardrails
• Expand, hold, or rollback decision

Examples

A workload oscillates because replica stabilization and vertical requests changed together. The team freezes vertical automation, tunes the managed HPA in a canary, and restores rightsizing on…

CAST AI Production Readiness Gate

Overview

Approve production only when identity, ownership, connectivity, observability, scaling safety, cost interpretation, rollback, and evidence are all explicit. An unchecked or unknown item is a stop, not a soft pass.

Prerequisites

• Exact production kube context and CAST AI organization/region
• Reviewed infrastructure plan and pinned artifacts
• Workload owners, SLOs, PDBs, HPAs, quotas, and maintenance window
• Incident, rollback, and support escalation owners

Instructions

Step 1: Verify identity and ownership

Use Read and Grep to prove cluster, organization, region, cloud account, IaC source, reconcilers, and secret references. Confirm one owner for node provisioning, vertical rightsizing, and each HPA.

Step 2: Verify installation and access

Use Bash(castctl:) for supported version or status inspection, Bash(helm:) for pinned release evidence, and Bash(kubectl:\*) for component readiness and warning events. Confirm least-privilege cloud permissions and required outbound connectivity.

Step 3: Verify scaling guardrails

Review node templates, maximum CPU, cloud quotas, protected namespaces, workload policy assignment, minimum/maximum requests, apply mode, recommendation confidence, PDB behavior, HPA bounds, and ownership transfer. Reject deprecated cluster minimum CPU configuration.

Step 4: Verify cost and reporting

Confirm baseline source, representative data window, public versus adjusted prices, automation adoption, and reconciliation owner. Do not use available or modeled savings as an unconditional release gate.

Step 5: Verify delivery and rollback

Use Bash(terraform:) for the saved plan and Bash(helm:) for the reviewed render. Confirm no unexpected deletion, disconnect, IAM expansion, CRD replacement, webhook collision, or automation enablement. Use Write or Edit to record tested rollback steps and thresholds.

Step 6: Make the decision

Record PASS only when every required item has evidence. Otherwise record HOLD with the exact owner and missing proof. Approve one cluster ring and one automation dimension at a time.

Tool Discipline

Use Read and Grep for evidence review. Use Write and Edit for the signed gate record. Use Bash(kubectl:), Bash(helm:), Bash(terraform:), and Bash(castctl:) for non-secret inspection, render, and plan operations; do not perform the production change from the checklist.

Output

• Evidence-linked readiness matrix
• Explicit PASS or HOLD decision
• Approved scope, window, and owners
• Rollback and incident triggers

Examples

A cluster passes observation readiness but holds node automation because Karpenter ownership is unresolved. Another passes a Deferred workload canary while managed HPA t…

CAST AI Request-Budget Control

Overview

Treat rate capacity as an endpoint-specific runtime signal, not a single invented requests-per-second number. Bound concurrency, retries, polling, and total work while preserving correct authentication and organization scope.

Prerequisites

• Client path, CAST AI region, organization scope, endpoints, and workload volume
• Current API specification and observed response headers
• Idempotency classification and business deadline for every operation

Instructions

Step 1: Inventory request producers

Use Read and Grep to identify direct API calls, Terraform operations, polling loops, scheduled jobs, retries, pagination, and per-cluster fan-out. Calculate worst-case attempts, not only successful requests.

Step 2: Classify operations

Separate reads, idempotent updates, and non-idempotent mutations. Only retry operations whose semantics are proven safe. Keep auth failures, permission denials, malformed requests, and policy rejections outside the retry path.

Step 3: Define the budget

Use Write or Edit to set per-endpoint concurrency, maximum attempts, maximum elapsed time, request timeout, queue capacity, and global job ceiling. Because CAST AI documents endpoint-dependent limits plus an upstream edge limiter, derive values from current specification and observed behavior.

Step 4: Handle throttling

On 429, honor a valid server-provided delay signal when present; otherwise use capped exponential backoff with jitter. Coordinate workers through one limiter, stop adding retries after the deadline, and avoid synchronized polling at fixed boundaries.

Step 5: Reduce demand

Cache stable reads within their acceptable staleness window, collapse duplicate requests, paginate deliberately, query only required organizations and clusters, and replace rapid status polling with a slower bounded schedule or documented notification path when suitable.

Step 6: Test the failure envelope

Add deterministic tests for 429 with and without delay metadata, repeated 5xx, timeout, cancellation, queue overflow, deadline exhaustion, non-idempotent mutation, and mixed-region credentials. Assert no infinite loop and no duplicate unsafe mutation.

Tool Discipline

Use Read and Grep for client and specification analysis. Use Write and Edit for limiter logic, tests, and operational documentation. This skill does not send live requests or guess undocumented quota values.

Output

• Request inventory and idempotency map
• Endpoint-specific concurrency and retry budget
• Deterministic throttling and exhaustion tests
• Metrics for attempts, delay, queue depth, 429s, and dropped work

Examples

A nightly collector shares one limiter across cluster workers and stops at its batch deadline. A policy mutation returns 42…

CAST AI Reference Architecture

Overview

Describe the real control and data paths for one estate. Avoid a generic vendor diagram: show where identity, telemetry, recommendations, mutations, cloud provisioning, GitOps, and operator approvals actually cross boundaries.

Prerequisites

• Cluster inventory, providers, regions, network zones, and CAST AI organizations
• Selected modes: read-only, Workload Autoscaler, Node Autoscaler, or full
• IaC/GitOps ownership, existing provisioners, HPAs, PDBs, and data policy

Instructions

Step 1: Establish trust zones

Use Read and Grep to map CAST AI hosted services, regional API base, enterprise or organization identity, cloud accounts, Kubernetes API servers, CI, GitOps controllers, secret managers, and operator workstations.

Step 2: Map in-cluster components by mode

Represent the unified umbrella chart and its selected tag mode. Shared components include the agent, spot handler, and Kvisor; automation modes add controllers, evictor, pod mutator, workload autoscaler/exporter, pod pinner, or live-migration components as documented. Do not show every component as present unconditionally.

Step 3: Map control paths

Separate observation snapshots, cost telemetry, workload recommendations, mutating admission, Eviction API operations, native HPA management, pending-pod observation, node provisioning, and cloud API calls. Label which paths read, recommend, mutate, or provision.

Step 4: Map permission boundaries

Show human castctl login, service API keys, enterprise child-organization targeting, Kubernetes service accounts, cloud IAM, and optional Kvisor capabilities. Link each privilege to a feature and identify the revocation owner.

Step 5: Map configuration authority

Use Write or Edit to declare whether castctl, Terraform, Helm GitOps, console, or workload annotations own each setting. Highlight conflicts with Karpenter, cloud autoscalers, native HPAs, and manual console changes.

Step 6: Add failure and rollback paths

Include regional API loss, agent disconnect, missing metrics, webhook failure, exhausted cloud quota, unsatisfied node template, PDB denial, and bad policy rollout. Show observation continuity, fail-safe behavior, escalation, and rollback authority.

Tool Discipline

Use Read and Grep for repository and environment evidence. Use Write and Edit for the architecture record and diagram source. Do not infer selected features, components, permissions, or network reachability from a default installation.

Output

• Trust-zone and component view
• Read/recommend/mutate/provision data-flow view
• Identity, permission, and configuration-authority matrix
• Failure, rollback, and escalation paths

Examples

A read-only cluster shows telemetry components but no node provision…

CAST AI Contract-First API Adapter

Overview

Create a narrow adapter around approved CAST AI operations. Treat the OpenAPI description, regional base URL, organization scope, response schemas, and endpoint-specific rate behavior as explicit dependencies.

Prerequisites

• Named operations and business purpose
• CAST AI region, organization boundary, and least-privilege service identity
• Current OpenAPI contract pinned or checksummed for generation
• Error, retry, telemetry, and secret-handling policy

Instructions

Step 1: Choose API versus Terraform

Use Read and Grep to determine whether the work is declarative infrastructure or runtime integration. Prefer the supported Terraform provider for owned desired state; use REST for bounded runtime reads or operations that the chosen provider does not own.

Step 2: Pin the contract

Record the current API specification origin, retrieval time, checksum, selected operation IDs, and generated-client tool version. Do not copy guessed paths from examples or expose the entire generated surface to application code.

Step 3: Build the transport boundary

Use Write or Edit to implement injected regional base URL, X-API-Key header handling, optional enterprise organization header, request timeout, cancellation, bounded response size, structured redaction, and correlation metadata. Never place keys in URLs or exception messages.

Step 4: Normalize domain operations

Expose small intent-oriented methods with validated identifiers and typed results. Keep raw provider payloads behind the adapter, retain unknown fields safely, and distinguish absent data from zero values.

Step 5: Classify failures

Map transport failures, 401, 403, 404, 409, endpoint-specific 429, 5xx, schema mismatch, deadline exhaustion, and uncertain mutation outcome. Retry only proven idempotent operations within a shared request budget.

Step 6: Test without CAST AI

Add fixtures for every status class, regional mismatch, enterprise header omission, pagination, unknown fields, redaction, timeout, cancellation, and throttling. Keep an optional live smoke test read-only and separately protected.

Tool Discipline

Use Read and Grep for contract and repository discovery. Use Write and Edit for the adapter, fixtures, tests, and contract receipt. This skill does not fetch credentials, call production, or claim an unofficial library is vendor-supported.

Output

• API-versus-Terraform ownership decision
• Pinned contract receipt and selected operations
• Narrow authenticated adapter with normalized failures
• Offline contract suite and protected smoke-test boundary

Examples

A reporting service wraps two read operations and hides generated types behind its own domain model. The same repository leaves cl…

CAST AI Least-Privilege Review

Overview

Review permissions against the components actually enabled. Distinguish observation, optimization, operator lifecycle, Kvisor telemetry, optional cluster proxy, and cloud-provider access instead of labeling the entire installation read-only or full-access.

Prerequisites

• Selected umbrella-chart mode and optional features
• Rendered Helm resources, service accounts, RBAC, cloud IAM, and secret references
• Organization roles, API-key inventory, network policy, and data-classification rules

Instructions

Step 1: Establish feature scope

Use Read and Grep to map read-only, Workload Autoscaler, Node Autoscaler, full, Kvisor options, reliability metrics, GPU or storage telemetry, operator management, and cluster proxy. Flag enabled components that lack a named business owner.

Step 2: Review identity boundaries

Separate human castctl login from service API keys. Verify organization role bindings, region, enterprise child targeting, storage, rotation, and revocation. Reject keys in values, URLs, Terraform output, logs, or support artifacts.

Step 3: Review Kubernetes permissions

Use Bash(helm:) to render the pinned installation and Bash(kubectl:) for bounded RBAC inspection. Compare each service account to current documented permissions. Account for agent deployment patching, operator lifecycle permissions, Kvisor cluster reads, optional scan jobs, and feature-gated token or pod-resize permissions.

Step 4: Review cloud permissions

Map each AWS, GCP, Azure, or other permission to monitoring, onboarding, automation, discovery, commitments, or storage telemetry. Do not reuse an automation role for read-only monitoring when the provider supports narrower access.

Step 5: Review network and data paths

Document regional egress, private connectivity, webhook destinations, telemetry classes, retention, and support-transfer controls. Do not invent a static IP allowlist or a broad 0.0.0.0/0 policy under the label of least privilege.

Step 6: Record disposition

Use Write or Edit to mark every finding KEEP, NARROW, REMOVE, or INVESTIGATE with owner, evidence, risk, and rollback. Treat Kvisor security documentation as evolving and verify current product scope before enabling a feature.

Tool Discipline

Use Read and Grep for configuration and permission mapping. Use Write and Edit for the review record. Use Bash(helm:) and Bash(kubectl:) only for rendered and effective RBAC inspection; never retrieve Secret data or mutate access.

Output

• Enabled-feature and component inventory
• Human, service, Kubernetes, and cloud identity matrix
• Network, telemetry, and retention boundary
• Evidence-linked permission dispositions

Examples

A read-only deployment retai…

CAST AI Upgrade and Umbrella Migration

Overview

Inventory the installed topology, pin the target, preserve values, and rehearse recovery before changing a cluster. Treat standalone-to-umbrella consolidation as a downtime-bearing migration, not an ordinary chart bump.

Prerequisites

• Exact kube context, installation owner, current releases, chart/provider locks, and target
• Maintenance window, workload and platform owners, rollback threshold, and evidence path
• Current backups of declared values and infrastructure state references without secret material

Instructions

Step 1: Classify the installation

Use Bash(helm:\*) to determine whether the namespace has one castai umbrella release or multiple standalone releases. Use Read and Grep to map Terraform, GitOps, console, and castctl ownership. Do not proceed while authorities conflict.

Step 2: Capture the baseline

Use Bash(kubectl:\*) for component images, readiness, recent warning events, policy-visible workload health, PDBs, HPAs, and pending pods. Record selected umbrella mode and optional component overrides.

Step 3: Review target and render

Pin the target chart or provider from current release metadata. Use Bash(helm:) to render the proposed umbrella values and Bash(terraform:) to save a reviewed plan when Terraform owns delivery. Inspect CRDs, RBAC, webhooks, component modes, removed values, and automation changes.

Step 4: Choose upgrade or migration

For an existing umbrella release, use the documented chart upgrade with --reset-then-reuse-values; Helm 3.14 or newer is required. Pin the current chart version when changing configuration without changing components. For standalone releases, use Bash(castctl:\*) with cluster migrate; expect a window where components and both autoscalers are paused.

Step 5: Protect recovery

Before standalone migration, set and protect the values-dump destination. If umbrella installation fails, preserve the generated values and debug snapshot, correct the conflict, then use documented values-file recovery. Do not publish dumps; they can contain sensitive configuration.

Step 6: Verify and promote

Confirm one intended release, component readiness, cluster identity, telemetry, policy state, automation mode, HPAs, PDBs, and node/workload behavior. Compare the baseline and hold promotion on any unexplained drift.

Tool Discipline

Use Read and Grep for release and ownership evidence. Use Write and Edit for the plan and recovery record. Use Bash(helm:), Bash(terraform:), Bash(kubectl:), and Bash(castctl:) only inside the approved render, migration, upgrade, and verification boundaries.

Output

• Current-versus-target topology and artifact pins
• Reviewed upgrade or migration plan
• P…

CAST AI Webhook Notification Lane

Overview

Route only actionable CAST AI notifications to a hardened receiver. Treat the console-configured request template as the payload contract and the CAST AI Audit log as reconciliation evidence, not as a guessed public event schema.

Prerequisites

• CAST AI organization, notification owner, severity policy, and receiver
• HTTPS endpoint with authentication, request limits, retention, and on-call ownership
• Sanitized sample template and failure fixture

Instructions

Step 1: Define the event contract

Use Read and Grep to identify required severity levels, cluster and organization scope, destination, payload fields, privacy classification, deduplication key, and escalation behavior. Exclude fields the receiver does not need.

Step 2: Harden the receiver

Require TLS, an authenticated boundary appropriate to the chosen integration, bounded body size, content-type validation, request timeout, concurrency limit, replay resistance, redacted logs, and a durable queue. Do not claim CAST AI sends a signature or header unless the configured product flow documents it.

Step 3: Configure the notification

In the CAST AI organization, create a webhook with a clear name, callback URL, severity triggers, and valid JSON request template. Use Write or Edit to version the receiver's expected template and schema tests without committing destination secrets.

Step 4: Normalize and route

Parse required fields defensively, preserve unknown fields, normalize timestamps, derive a stable deduplication key from configured content, and map severity through an approved table. A notification should enrich an incident, not directly mutate CAST AI or Kubernetes.

Step 5: Test all outcomes

Test valid, unknown-field, missing-optional-field, malformed, oversized, unauthorized, duplicate, delayed, and receiver-down cases. Verify bounded retry/queue behavior and that payloads or credentials do not leak into logs.

Step 6: Reconcile with the Audit log

Use the CAST AI console Audit log to confirm user-initiated and automated policy operations around the test window. Record what the webhook delivered, what the audit view shows, and any known coverage gap.

Tool Discipline

Use Read and Grep for receiver, runbook, and payload-contract discovery. Use Write and Edit for the versioned template, schema, tests, routing policy, and operational record. This skill does not create a live webhook or send test traffic without an approved external change.

Output

• Severity, payload, and privacy contract
• Hardened receiver behavior and schema tests
• Deduplication, routing, and outage policy
• Webhook-versus-Audit-log reconciliation receipt

Examples

A critical notification opens or enriches one incident using a stable…