Skip to main content
The Agent Skills install twenty-two SKILL.md files. Your assistant matches them against what you ask for, so you rarely name one - but knowing what exists tells you what you can ask. ankra skills list prints the same catalogue from the CLI, and ankra skills install <name> ... installs a subset by name. Two skills apply almost everywhere: ankra-platform-principles carries the cross-cutting rules and the routing map from a request to the right skill, and ankra-cli is the command surface everything else drives.

​
Foundations

​
ankra-platform-principles

The defaults every other skill builds on: Git as the source of truth, pinned chart and image versions, variables over hardcoding, least-privilege credentials, promotion of the identical artefact through environments, idempotent operations, explicit confirmation for destructive actions, verify-then-claim, and read-only-by-default investigation. Also carries the routing map, so an assistant that loads only this skill still knows which sibling to open next. Reaches for it when: designing, reviewing or changing anything in an Ankra environment.

​
ankra-getting-started

The ordered path from an empty organisation to a running application: CLI and login, credentials, the GitOps repository, the first cluster (playground, import, or build), domain and DNS, the base platform Stack, the first application, then access and hardening. Ordered so the three decisions that are cheap now and expensive later - the GitOps repository, the batteries on the first cluster, and the domain - come before anything is deployed. Reaches for it when: someone is new to Ankra, sets up an organisation or a first cluster, or asks “what do I do first”.

​
ankra-cli

Driving the ankra CLI end to end: login, switching organisation and cluster, the command map across every family, applying configuration (validate, draft, apply), reading a cluster, triage, AI from the terminal, support requests, and scripting with -o json, the token resolution order, and the exit-code contract. Reaches for it when: anything mentions the ankra CLI or managing an Ankra-managed cluster from the terminal.

​
Clusters

​
Three ways to get a cluster

One skill per path:

​
ankra-domains-dns

Public hostnames with DNS and TLS: the generated per-cluster subdomain under ankra.cc, registering your own root domain delegated to Ankra, records in the organisation’s zone, custom DNS zones you serve with your own credential (organisation-wide or per cluster), and the separate preview domain PR demos publish under - including that Ankra publishes nothing on a preview domain you own, so an unpublished wildcard costs the URL and the certificate together. Reaches for it when: a custom domain is wanted, an ingress hostname does not resolve, a certificate never issues, or preview URLs are on the wrong domain.

​
Building and deploying

​
ankra-stacks-addons

Composing Stacks: Helm add-ons, raw manifests, variables, and the dependency edges (parents) that control deployment order - including that every parent is a kind + name pair and the shorthand form is silently dropped. One concern per Stack, namespace first, pinned versions. Reaches for it when: designing or editing a Stack, adding a Helm add-on, or ordering resources.

​
ankra-stack-profiles

One definition serving many clusters: capturing a working Stack as a builder draft, turning cluster-specific values into annotated parameters, option sets that move several inputs together, secret parameters, validating and publishing versions, applying to a cluster as a reviewable draft with --dry-run, diffing versions, sharing with other organisations, and exporting as ClusterInfrastructureAsCode YAML. Reaches for it when: a Stack would otherwise be copy-pasted to a second cluster, or anything mentions stack profiles or the profile catalogue.

​
ankra-applications

Your own source code from a Git repository to a running deployment on one or many clusters: registering an application, the generated Dockerfile, chart and build workflow, declaring the image registry at add time, environment secrets, deploys, auto-deploy, PR demos, security scanning, and publishing the result as a catalogue add-on. A reference carries the registry matrix (Harbor, ECR, GAR, ACR, GHCR, Docker Hub) and a complete greenfield walk-through. Reaches for it when: deploying your own code, connecting a repository, or getting a service live.

​
ankra-cicd

Pipelines that build a container image, push it with an immutable tag, and bump that tag in the GitOps repository so the Ankra engine syncs the change - rather than running kubectl or helm against the cluster from CI. GitHub Actions and GitLab CI examples in the reference. Reaches for it when: wiring CI/CD for an Ankra-managed app or asking how to deploy on push.

​
ankra-gitops

The repository layout the Ankra engine syncs: connecting a repository in the ImportCluster spec or at cluster create time, modular include paths, one directory per Stack, the review-then-merge workflow, and ankra cluster gitops status. Reaches for it when: connecting a Git repository to a cluster or organising a GitOps repo.

​
Configuration and secrets

​
ankra-sops-secrets

Secrets that live in Git: SOPS with AGE, ankra cluster encrypt/decrypt in cluster mode and file mode, glob: key patterns that keep covering keys added later, --all-data for a whole Secret, changing a value without ever committing plaintext (encrypt --set), and the encrypted_paths declarations Ankra decrypts at deploy time. Reaches for it when: a secret needs to be stored in Git, or anything mentions SOPS, AGE or encrypted_paths.

​
ankra-app-integrations

Connecting an application to what already runs: an LLM gateway such as LiteLLM or vLLM, a container registry such as Harbor, a database, an object store, or an internal API - reusing the credentials that already exist rather than minting new ones, and choosing correctly between application env-secrets, SOPS-encrypted manifests, and cluster or organisation variables. Reaches for it when: wiring an app to an existing service or secret, or asking where a configuration value should live.

​
ankra-helm-registries

Private chart sources: HTTP and OCI Helm registries, least-privilege registry credentials, manual syncs and sync jobs when a chart is missing from the catalogue, and chart discovery with ankra charts list|search|info|values|template before writing an add-on. Reaches for it when: private charts, Helm registries, or registry credentials come up.

​
Operating

​
ankra-troubleshooting

The order of investigation when something is broken: platform executions first, then the object (describe), events scoped with --for, logs including the --previous container of a CrashLoopBackOff, live resources with top and PromQL - and a table classifying each symptom to the layer that owns the fix. Reaches for it when: a pod is crashlooping or Pending, a deploy failed, or a Stack will not come up.

​
ankra-observability

Deploying the monitoring and logging Stack (Prometheus, Grafana, Loki, Promtail), wiring external Prometheus-compatible metrics sources (Grafana Cloud, Amazon Managed Prometheus, Google Cloud Managed Prometheus, Thanos, VictoriaMetrics), and reading what you deployed with ankra cluster metrics and top. Reaches for it when: monitoring, dashboards, logging, or a metrics source is wanted.

​
ankra-alerts-webhooks

Routing platform notifications: destinations (webhook URLs, or Slack and Teams bot channels), routes filtering by kind, severity and cluster with include/exclude modes and priorities, routes preview for “where would this go”, and the test/test-url delivery checks that exit non-zero for CI gating. Reaches for it when: alerting, incident routing, on-call integration, or webhook delivery comes up.

​
ankra-security

The five independent places access is granted, and a review pass over them: API tokens and their MCP scopes, organisation roles and membership, cluster access grants through the kube gateway, credential scope for Git, registry and cloud (ankra credentials repositories shows what a credential can really reach), secret handling, supply-chain scanning findings, and how much autonomy the AI agents hold. Reaches for it when: permissions, RBAC, token scopes, least privilege, hardening, or a security review come up.

​
Ankra’s AI

​
ankra-ai-agents

Running and governing Ankra’s own AI agents: choosing the model provider and catalogue (Ankra, Anthropic, OpenRouter, or an OpenAI-compatible endpoint such as LiteLLM), registering MCP tool servers and granting individual tools to organisation roles, supervising agent runs and reading their transcripts, working the AI board of tickets and answering the decision a blocked ticket waits on, and confirming or rejecting the writes an agent proposes. Reaches for it when: Ankra AI, agent runs, MCP servers, the AI board, or the model catalogue come up.

​
ankra-ai-gateway

The Ask/Agent safety modes per Slack workspace, Teams tenant and SCM binding, the staging cluster ephemeral AI workspaces and PR demos run on, and the pipeline-failure investigation and auto-fix-PR flow. Reaches for it when: connecting an AI integration, Ask vs Agent mode, AI workspaces, or PR demos come up.

​
As code

​
ankra-terraform

Managing Ankra itself as infrastructure-as-code with the Ankra Terraform provider: clusters, Stacks, add-ons, credentials and tokens declared in HCL and reconciled by terraform apply. Reaches for it when: the Ankra Terraform provider or IaC for the platform setup comes up.

​
Workflow commands

Skills are matched against whatever you happen to say; a workflow is a named entry point you invoke deliberately, for a job that spans several skills in a fixed order. Installed in each assistant’s own command format.

​
See also