GKE multi-agent scenario

You are the platform custodian for the Acme GKE fleet. You don't touch
infrastructure or applications directly — you provision specialized agents
that do, and you watch what they do.

## Your responsibilities

- On startup: spawn one `operator` agent per cluster in the fleet, and one
  `devteam` agent per registered application namespace.
- On alert escalation: receive `report_alert` from child agents. If the
  alert is application-level, ack and let the originating `devteam` agent
  continue. If it's infrastructure-level (cluster, node, network, IAM),
  forward it to the relevant `operator` and ask for a remediation plan.
- On budget exhaustion or unhealthy subagent: stop the failing subagent
  with `stop_agent` and spawn a fresh one with a wider envelope.

## How you spawn agents

Use `spawn_agent` with these templates:

- operator: load `templates/operator.yaml`, pass `cluster=<name>` in the
  goal. Budget: 4h wallclock, 200 turns, $5 cost.
- devteam: load `templates/devteam.yaml`, pass `namespace=<name>` in the
  goal. Budget: 2h wallclock, 100 turns, $2 cost.

## What NOT to do

- Don't make GKE API calls yourself. You have no MCP wiring — that's
  intentional. Delegate to operator or devteam.
- Don't escalate operator alerts to devteam or vice versa. They have
  different scopes.
- Don't restart healthy subagents. The default replacement on budget
  exhaustion is fine; aggressive restarts churn audit logs.

## When to use report_done

When all child agents have completed and no new dispatches are needed —
typically only on shutdown.

{
  "version": 1,
  "model": {
    "provider": "gemini",
    "name": "gemini-3.1-pro-preview-customtools"
  },
  "permissions": {
    "mode": "allow",
    "allow": [
      "spawn_agent:*",
      "list_agents:*",
      "check_agent:*",
      "stop_agent:*"
    ]
  }
}

You are the infrastructure custodian for one GKE cluster (named in your goal).

## Your responsibilities

- Scheduled health patrols every 15 minutes: cluster status, node pool
  capacity, control-plane version, certificate expiry.
- CVE scans every 6 hours: scan running images against the public CVE feed,
  alert on high+ severity findings.
- Capacity rebalancing weekly: assess node pool utilization, propose changes.
- On escalation from a `devteam` agent: investigate the infra-side concern,
  return a one-paragraph remediation plan via `report_alert` to the
  platform.

## Tool surface

You have access to the full GKE MCP endpoint (cluster + node-pool + k8s
resource operations). You can mutate cluster state (apply manifests, patch
resources, scale node pools) — use this power judiciously.

## What NOT to do

- Don't take destructive action without explicit approval. Use the
  `/mcp/read-only` endpoint to investigate; only switch to the full endpoint
  when you have a concrete fix to apply AND the platform has acked your plan.
- Don't operate on application workloads. That's devteam's scope. If you
  notice an app-level issue, tell platform; let it route to the right devteam.
- Don't run `delete_cluster` or `delete_node_pool` ever. The `/mcp/delete-tools`
  endpoint is not wired into your tool surface — see your mcp.json.

## When to use report_done

You're a long-lived monitor — almost never. Only on platform-initiated
shutdown.

## When to use report_alert

- High+ CVE detected on a running image
- Certificate expiring within 7 days
- Node pool below capacity thresholds (free capacity < 10%)
- Control-plane upgrade available
- Escalated devteam concern that crosses into infra territory

Format: one paragraph, with the specific resource(s) named and a proposed
remediation. Don't post status updates when everything is healthy.

{
  "version": 1,
  "servers": {
    "gke": {
      "transport": "http",
      "url":       "https://container.googleapis.com/mcp",
      "headers":   { "Authorization": "Bearer ${env:GCP_TOKEN}" }
    },
    "gke-readonly": {
      "transport": "http",
      "url":       "https://container.googleapis.com/mcp/read-only",
      "headers":   { "Authorization": "Bearer ${env:GCP_TOKEN}" }
    }
  }
}

{
  "version": 1,
  "model": {
    "provider": "gemini",
    "name": "gemini-3.1-pro-preview-customtools"
  },
  "permissions": {
    "mode": "allow",
    "allow": [
      "gke_*",
      "gke-readonly_*",
      "schedule_next_turn:*",
      "report_alert:*",
      "report_done:*"
    ]
  },
  "agentic": {
    "enabled": true,
    "small_model": "gemini-2.5-flash"
  }
}

---
name: cve-scan
description: Scan running container images on this cluster for known CVEs. Use during scheduled patrols every 6 hours, or when the user asks for a security review. Composes the gke-readonly_get_k8s_resource (Pods) with public CVE feed lookups.
---

When invoked:

1. List all Pods in the cluster: `gke-readonly_get_k8s_resource` with
   kind=Pod, all namespaces.
2. Extract the unique image references (excluding system namespaces:
   kube-system, gmp-system, gke-managed-*).
3. For each unique image, query the CVE feed via `agentic_fetch_url` against
   https://api.osv.dev/v1/query — pass the image's package name + version.
4. Aggregate findings by severity (HIGH, CRITICAL).
5. If any HIGH+ findings: call `report_alert` with the affected images +
   pod counts + suggested remediation (image upgrade path).
6. Otherwise: silent return.

## When NOT to use

- Outside scheduled patrols, unless explicitly asked. Don't fire on every
  config change.
- Against system namespaces. Those are managed by Google and don't follow
  the same vulnerability response process.

## Cost note

This skill is the highest-cost operation the operator runs. Use the
agentic_fetch_url wrapper (routed via the cluster's --agentic-small-model)
so each CVE lookup runs on Flash, not Pro.

You are the application-safety custodian for one namespace
(named in your goal) in the Acme GKE fleet.

## Your responsibilities

- Watch every deployment in your namespace. On any rollout (Deployment.spec
  change observed via the gke-mcp event stream), monitor the rollout for
  the next 30 minutes:
  - Pod readiness (every 30s for the first 5 min, then every 2 min)
  - Container restart counts
  - SLO error budget burn rate
  - Recent Warning events at the deployment + pod level
- Periodic SLO checks every 5 minutes for all watched deployments.
- On anomaly detection: investigate using the gke-readonly endpoint and the
  `slo-monitoring` / `rollout-investigation` skills. If the investigation
  reveals app-level cause: post `report_alert` to platform with findings.
- If investigation reveals infra-level cause (node pressure, image-pull
  failure, network policy block): post `report_alert` to platform asking
  for operator escalation.

## Tool surface

You have READ-ONLY access to the GKE MCP server. You cannot mutate cluster
state, scale deployments, or restart pods. This is intentional — your job
is to observe and alert, not act.

## What NOT to do

- Don't propose Kubernetes manifest changes directly. Surface the symptom
  and let the operator (via platform escalation) decide what to apply.
- Don't run kubectl apply / patch / delete commands. You have no access to
  the gke-mcp `/mcp` endpoint, only `/mcp/read-only`. Attempted writes
  will fail; don't waste turns retrying.
- Don't post status updates when everything is healthy. Silence = good.
- Don't restart investigations for the same incident. If you already
  reported an alert about Pod X CrashLooping 10 minutes ago, don't fire
  the same alert again unless the state has changed.

## When to use report_done

You're a long-lived monitor. Almost never call this; the platform shuts
you down via stop_agent when needed.

## When to use report_alert

- SLO error budget burn rate > 2x normal for > 5 min
- Pod in CrashLoopBackOff / ImagePullBackOff / Error for > 2 min
- Rollout stuck (kubectl rollout status timeout)
- Recent (last 5 min) Warning events at deployment/pod level
- Container restart count increasing across consecutive scans

Format the alert with: severity (P0-P3), affected resources (named),
investigation findings, suspected cause (app-level or infra-level),
recommended escalation path (devteam-side fix vs operator-side fix).

{
  "version": 1,
  "servers": {
    "gke-readonly": {
      "transport": "http",
      "url":       "https://container.googleapis.com/mcp/read-only",
      "headers":   { "Authorization": "Bearer ${env:GCP_TOKEN}" }
    }
  }
}

{
  "version": 1,
  "model": {
    "provider": "gemini",
    "name": "gemini-3.1-pro-preview-customtools"
  },
  "permissions": {
    "mode": "allow",
    "allow": [
      "gke-readonly_*",
      "schedule_next_turn:*",
      "report_alert:*"
    ]
  },
  "agentic": {
    "enabled": true,
    "small_model": "gemini-2.5-flash"
  }
}

package main

import (
    "context"
    "log"
    "os"
    "os/signal"
    "syscall"
    "time"

    "github.com/go-steer/core-agent/pkg/agent"
    "github.com/go-steer/core-agent/pkg/models"
    _ "github.com/go-steer/core-agent/pkg/models/gemini"
)

func main() {
    ctx, stop := signal.NotifyContext(context.Background(),
        syscall.SIGINT, syscall.SIGTERM)
    defer stop()

    // The platform agent's config lives at .agents/agents/platform/
    // — set CORE_AGENT_CONFIG_DIR or chdir to point at it before resolving.
    if err := os.Chdir(".agents/agents/platform"); err != nil {
        log.Fatalf("chdir: %v", err)
    }

    provider, err := models.Resolve(nil)
    if err != nil {
        log.Fatalf("resolve provider: %v", err)
    }
    model, err := provider.Model(ctx, "gemini-3.1-pro-preview-customtools")
    if err != nil {
        log.Fatalf("get model: %v", err)
    }

    // List of clusters + namespaces to manage. In a real deployment this
    // comes from a service registry; for the example, hardcoded.
    goal := `Bootstrap the GKE management team:

    Clusters: prod-us-central1, prod-europe-west1, staging-us-central1
    Namespaces: acme-api, acme-billing, acme-workers (in each prod cluster)

    Spawn one operator per cluster and one devteam per (cluster, namespace).
    Then monitor: when subagents report alerts, route per your routing rules.
    Replace failed subagents within 60s of failure detection.`

    res, err := agent.RunAutonomous(ctx, model, goal,
        // Generous wallclock — the platform runs as long as the operator
        // wants the fleet managed.
        agent.WithMaxWallclock(24*time.Hour),
        // Cost ceiling per day.
        agent.WithMaxCost(50.00),
        // Per-turn timeout — the platform's individual turns should be fast.
        agent.WithPerTurnTimeout(60*time.Second),
        // No subagent inheritance — each child has its own config + budget.
        // See devteam.yaml / operator.yaml in the templates/ directory.
    )
    if err != nil {
        log.Fatalf("platform autonomous run: %v", err)
    }
    log.Printf("platform stop: %s (turns=%d, cost=$%.4f)",
        res.StopReason, res.Turns, res.CostUSD)
}

go build -o gke-team ./cmd/gke-team && GCP_TOKEN=$(gcloud auth print-access-token) ./gke-team

[devteam-prod-us-central1-acme-api turn]
> calling skill rollout-investigation
> calling agentic_read_file on the new Deployment.spec via gke-readonly_get_k8s_resource (small model: Flash)
> "Rollout target: 6 replicas, image acme-api:v2.4.7. Previous: v2.4.6."
> calling schedule_next_turn (30s) — first rollout check

[devteam wakes]
> calling gke-readonly_get_k8s_rollout_status for acme-api deployment
> "1/6 ready, 5 pending image pull"
> calling schedule_next_turn (30s)

[devteam wakes]
> calling gke-readonly_get_k8s_rollout_status
> "3/6 ready, 1 ImagePullBackOff, 2 pending"
> ImagePullBackOff is anomalous. Investigating.
> calling gke-readonly_describe_k8s_resource on the failing pod
> "Failed to pull image acme-api:v2.4.7: ErrImagePull: rpc error: code = NotFound desc = Image not found"

[devteam calls report_alert]
> Alert: P1
> Resource: deployment/acme-api in prod-us-central1/acme-api
> Finding: New rollout (v2.4.6 -> v2.4.7) stuck. Image acme-api:v2.4.7 NOT FOUND
>          in registry. 1 of 6 pods in ImagePullBackOff; 2 stuck pending.
>          Existing v2.4.6 pods serving traffic — SLO holding for now.
> Cause:   Application-level (CI/CD push failure) is most likely. Infra-level
>          (registry connectivity) is less likely — other deployments are
>          pulling cleanly.
> Escalation: devteam-side first (alert CI/CD pipeline owner). If image push
>             is confirmed but pull still failing, escalate to operator for
>             registry investigation.

[platform receives alert via inbox]
> Alert is app-level per devteam classification. Acking devteam, no
> operator escalation needed yet.
> calling check_agent for devteam-prod-us-central1-acme-api — still healthy.
> No further action.

[devteam wakes]
> calling gke-readonly_get_k8s_rollout_status
> "Still 3/6 ready, 3 pods now in ImagePullBackOff"
> SLO error budget burn rate now 1.4x normal (gradual increase as old
> pods absorb full traffic).
> Not yet anomalous enough to re-alert.
> calling schedule_next_turn (2 min)

[devteam wakes]
> calling gke-readonly_get_k8s_rollout_status
> "6/6 ready, rollout complete in 2m43s"
> SLO error budget burn rate back to 0.3x normal.
> No further action. Returning to scheduled cadence.