> ## Documentation Index > Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt > Use this file to discover all available pages before exploring further. # Agent Skills Catalogue > Every Ankra Agent Skill and the workflow commands, what each one covers, and when your assistant reaches for it. The [Agent Skills](/integrations/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 ...` 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: | Skill | Path | Covers | | -------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ankra-import-cluster` | Adopt a cluster you already run | Authoring and applying `ImportCluster` YAML: the GitOps wiring, stacks of manifests and Helm add-ons, dependency ordering with `parents`, validate and draft before apply | | `ankra-cloud-clusters` | Ankra builds it on your infrastructure | Hetzner, OVHcloud, UpCloud, DigitalOcean, Proxmox VE, HPE Morpheus and Scaleway: choosing region and instance family from live discovery, k3s vs kubeadm and etcd topology, the ingress/DNS/CCM batteries, GitOps at create time, availability zones, node groups, upgrades, and the difference between power, teardown and delete. A reference carries the per-provider instance-family guide, role sizing, GPU node groups and cost traps | | `ankra-managed-kubernetes` | The provider runs the control plane | DOKS, UKS, GKE, OVH MKS, AKS, EKS and Kapsule: create with the first node pool and GitOps wiring, discover and adopt clusters that already exist, node pools and autoscaling, version upgrades, deletion | ### 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. | Command | What it runs | Leans on | | --------------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------- | | `/ankra-new-cluster` | Stand up a cluster from provider choice to a hostname that resolves with TLS | `ankra-getting-started`, `ankra-cloud-clusters`, `ankra-domains-dns` | | `/ankra-ship-service` | Source code to a production deployment on one or many clusters | `ankra-applications`, `ankra-cicd`, `ankra-stack-profiles` | | `/ankra-connect-app` | Connect an app to an existing service and its secrets | `ankra-app-integrations`, `ankra-sops-secrets` | | `/ankra-triage` | Investigate a failing workload, deploy or operation, read-only until diagnosed | `ankra-troubleshooting` | | `/ankra-promote` | Promote a verified change to the next environment without rebuilding it | `ankra-platform-principles`, `ankra-stack-profiles`, `ankra-gitops` | | `/ankra-harden` | A ranked security pass over the organisation | `ankra-security`, `ankra-sops-secrets` | | `/ankra-profile` | Capture a working Stack as a reusable, parameterised stack profile | `ankra-stack-profiles`, `ankra-stacks-addons` | ## See also * [Agent Skills](/integrations/agent-skills) - installing, the supported assistants, and what else an install writes. * [`ankra skills` reference](/reference/cli/skills) - every flag and subcommand.