Skip to main content

Skills and Memory

Extend the agent with domain skills and persistent memory across sessions

k8s-autopilot uses skills and memory to build deep domain knowledge and remember operational preferences:

  • Skills: Modular instruction sets that give the agent domain expertise — Helm workflows, Prometheus alerting patterns, GitOps procedures, and more. Skills come from built-in sub-agents and installed marketplace plugins.
  • Memory: AGENTS.md files that persist conventions, naming schemes, and cluster topologies across sessions, so the agent never forgets what you've taught it.

Skills​

Skills are the primary mechanism through which k8s-autopilot acquires deep operational knowledge. Each skill is a directory containing a SKILL.md file with step-by-step procedures, reference patterns, and safety rules for a specific operational domain.

Where Skills Come From​

Since k8s-autopilot runs as a centralized server that clients connect to, skills are loaded from two sources:

SourceHow They Work
Built-in sub-agent skillsBundled directly with each operator — Helm, Kubernetes, Observability (Prometheus, Loki, Tempo), and App Delivery (ArgoCD, Argo Rollouts). These ship verified with k8s-autopilot and are always available.
Plugin skillsInstalled from community marketplaces or custom Git repositories via the Settings UI. These extend the agent with new capabilities for any domain.

Built-in skills load automatically when their corresponding operator is activated. Plugin skills become available as soon as the plugin is installed — no restart needed.

How Skills Activate​

Skills activate automatically based on your task. The agent matches skills to your prompt using their semantic descriptions:

  • If you ask about Helm deployments, the Helm operator's skills load automatically.
  • If you ask about Prometheus alerting rules or Alertmanager silences, the observability skills activate.
  • You never need to configure or trigger anything manually.

Two Kinds of Skills​

  • Sub-agent skills: Bundled with specific operators (Helm Operator, Observability Operator, etc.). These only load when that sub-agent is active — they do not consume tokens during general conversation. Each sub-agent's skills are scoped exclusively to that sub-agent.
  • Plugin skills: Installed from marketplace plugins. If the plugin is an agent plugin, its skills are scoped to the plugin's dedicated sub-agent. If it's a vertical plugin, its skills bind directly to the main Supervisor agent and are available in every conversation.

Skill Structure​

A skill is a directory with a SKILL.md file and optional supporting assets:

my-skill/
├── SKILL.md          # Required — instructions with YAML frontmatter
├── scripts/          # Optional — helper scripts
├── references/       # Optional — domain-specific documentation and patterns
└── assets/           # Optional — templates, manifests, and examples

SKILL.md Format​

---
name: kubernetes-hardening
description: "Audit and enforce Pod Security Standards across Kubernetes namespaces"
tags: [security, kubernetes, compliance]
---

# Kubernetes Hardening Skill

When auditing or enforcing pod security:

1. Check all namespaces for PSA labels (enforce, audit, warn) at baseline or restricted level
2. Identify privileged containers and flag workloads running as root
3. Verify NetworkPolicies exist with default-deny ingress in each namespace
4. Check for missing resource limits and security contexts
5. Generate a compliance report with findings and recommended remediations

The YAML frontmatter provides the name and description that the agent uses for automatic skill matching.

Installing Skills via Plugins​

The primary way to add new skills to k8s-autopilot is through the plugin system:

  1. Go to Settings → Plugins and connect a marketplace.
  2. Browse the Discover tab to find plugins with the skills you need.
  3. Click Install — the plugin's skills are immediately available to the agent.

Each plugin card in the marketplace shows exactly which skills it includes, so you can inspect capabilities before installing. See Plugins & Marketplace for the full walkthrough.

Skill Persistence​

Installed plugin skills are persisted in the database so they survive container redeployments. If a skill file is missing from disk but exists in the database, k8s-autopilot automatically restores it. Built-in sub-agent skills are part of the codebase and do not require database restoration.

Skill Trust​

To prevent unauthorized skills from running, k8s-autopilot tracks trust decisions for newly discovered skills:

  • Built-in skills are automatically trusted.
  • Skills from newly installed plugins are approved when you install the plugin from the UI.

Memory​

What Memory Does​

As you work with k8s-autopilot, it learns your environment's preferences and conventions. When you tell it:

Remember that we always use ingress-nginx class "internal" for staging namespaces

It saves this to the AGENTS.md memory file and remembers it across all future sessions — no need to repeat yourself.

Memory is where the agent stores things it learns during work: preferred Helm chart sources, naming conventions, cluster topology patterns, and operational preferences.

AGENTS.md​

AGENTS.md is the primary memory file. It is loaded at the start of every session and injected into the agent's context so it adheres to your team's established conventions.

## Project Conventions

- All Helm releases must target the `platform` namespace unless explicitly specified
- Use `sealed-secrets` for all secret management — never commit plain Kubernetes Secrets
- Prometheus ServiceMonitors must include `release: kube-prometheus-stack` label
- All deployments require resource limits, liveness probes, and readiness probes

## Cluster Topology

- Staging: `eks-staging-us-east-1` (context: staging)
- Production: `eks-prod-us-east-1` (context: production)
- Always verify context before mutating operations

What to Store in Memory​

Store in MemoryDo NOT Store in Memory
Team conventions and naming standardsAPI keys, tokens, or credentials (use Settings UI)
Cluster topology and environment mappingsTransient diagnostic output or temporary troubleshooting notes
Preferred tools, registries, and chart repositoriesOne-off task details irrelevant to future sessions
Architectural patterns and operational preferencesMassive log files or raw metric outputs
Corrections you've given the agent

Protected Memory Regions​

Some sections of AGENTS.md are machine-managed — such as onboarding preferences and system configurations. These sections are protected by marker comments and cannot be modified by the agent, even if it edits other parts of the file. If the agent accidentally changes a protected block, the system automatically restores it.

Next Steps​