Update to Testkube Skills

{
  "name": "testkube",
  "description": "Orientation and routing for Testkube — the open testing platform that runs tests as Kubernetes-native TestWorkflows. Use when the user mentions Testkube, TestWorkflow, TestWorkflowTemplate, TestTrigger, a Testkube webhook, the `testkube` / `tk` / `kubectl-testkube` CLI, or a Testkube Control Plane or agent, and no more specific Testkube skill covers the task. ALSO use when the user asks to run tests (k6, Playwright, Cypress, JMeter, Postman, e2e, load) somewhere plain local execution cannot reach — in a Kubernetes cluster, in CI, on a schedule, or sharded at scale — even if Testkube is never named. Explains the platform model, indexes https://docs.testkube.io, and routes to the specialist skills (installing-testkube-cli, installing-testkube-oss-agent, test-discovery, testworkflow-author, testworkflow-runner). Prefer current docs over pre-trained knowledge. Orients and routes only — does NOT install, author YAML, or run executions, and says so when the tests should simply be run locally.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 223
    }
  ],
  "skill_md_contents": "---\nname: testkube\ndescription: \"Orientation and routing for Testkube — the open testing platform that runs tests as Kubernetes-native TestWorkflows. Use when the user mentions Testkube, TestWorkflow, TestWorkflowTemplate, TestTrigger, a Testkube webhook, the `testkube` / `tk` / `kubectl-testkube` CLI, or a Testkube Control Plane or agent, and no more specific Testkube skill covers the task. ALSO use when the user asks to run tests (k6, Playwright, Cypress, JMeter, Postman, e2e, load) somewhere plain local execution cannot reach — in a Kubernetes cluster, in CI, on a schedule, or sharded at scale — even if Testkube is never named. Explains the platform model, indexes https://docs.testkube.io, and routes to the specialist skills (installing-testkube-cli, installing-testkube-oss-agent, test-discovery, testworkflow-author, testworkflow-runner). Prefer current docs over pre-trained knowledge. Orients and routes only — does NOT install, author YAML, or run executions, and says so when the tests should simply be run locally.\"\n---\n\n# testkube\n\n[Testkube](https://testkube.io) is an open testing platform that runs tests inside Kubernetes. A test is declared as a\n`TestWorkflow` — a Kubernetes custom resource describing which container image to run, which repository to check out,\nand which commands to execute. Testkube turns that resource into a Kubernetes Job and reports back status, logs,\nartifacts, and JUnit results. Any framework that runs in a container runs in Testkube: Playwright, Cypress, k6, JMeter,\nPostman, Selenium, Go, Maven, Gradle, Robot Framework, and anything else with a CLI.\n\nTestkube runs in two shapes. **Open-source standalone** is a single agent in one cluster, driven entirely from the CLI.\n**Control Plane** (Testkube Cloud or on-prem) adds a dashboard, multi-environment management, and multiple connected\nagents with distinct capabilities. Which shape is in play changes what commands and features are available — see\n[Deployment topologies](#deployment-topologies) before answering questions about capabilities.\n\n**This skill orients and routes.** It teaches the platform model, indexes the docs, and points at the skill that does\nthe actual work. It does not install, author, or execute anything itself.\n\n## Retrieval sources\n\nTestkube ships faster than any model's training data. Fetch, do not recall.\n\n| Need                                     | Source                                                                          |\n| ---------------------------------------- | ------------------------------------------------------------------------------- |\n| Anything conceptual, current behavior    | https://docs.testkube.io — fetch the page                                        |\n| CLI verbs, flags, resource names         | `testkube <verb> <resource> --help` — run it                                     |\n| TestWorkflow field-level schema          | `../testworkflow-author/assets/workflow-schema.yaml`                             |\n| TestWorkflowTemplate schema              | `../testworkflow-author/assets/template-schema.yaml`                             |\n| Live CRD shape in a cluster              | `kubectl explain testworkflow.spec --recursive`                                  |\n| Deep TestWorkflow concepts               | `../testworkflow-author/references/docs-concepts.md`                             |\n| Worked YAML (22 frameworks)              | `../testworkflow-author/examples/` — indexed in `../testworkflow-author/references/examples-catalog.md` |\n| REST API                                 | https://docs.testkube.io/openapi/overview                                        |\n| CRD reference                            | https://docs.testkube.io/articles/crds                                           |\n| What changed recently                    | https://docs.testkube.io/changelog                                               |\n| A doc URL that 404s, or a page not indexed below | https://docs.testkube.io/sitemap.xml — every live page, authoritative     |\n\nWhen the docs and any bundled reference file disagree, **the docs win** — reference files are snapshots.\n\nThe [Docs index](#docs-index) below is curated and can go stale. **If a link from it 404s, do not guess a replacement\nslug — fetch the sitemap and find the current URL.**\n\n## Rules\n\nThese are mandatory. Violating any rule produces answers that look authoritative and are wrong.\n\n1. **MUST hand off to a specialist skill when one matches.** This skill orients; it does not execute. See\n   [Skill index](#skill-index).\n2. **MUST fetch the doc page before answering a factual question** about Testkube behavior, CLI flags, or CRD fields.\n   **MUST NOT** answer from memory — pre-trained knowledge of Testkube is stale and skews toward the deprecated\n   `Test` / `TestSuite` API.\n3. **MUST NOT invent CLI flags, CRD fields, or `apiVersion` values.** Verify against `--help`, the bundled schemas, or\n   the docs.\n4. **MUST NOT author or edit TestWorkflow YAML here** — that is `testworkflow-author`.\n5. **MUST NOT run, watch, or diagnose executions here** — that is `testworkflow-runner`.\n6. **MUST say so plainly when no skill covers the task**, then route to the doc URL and the relevant\n   `testkube ... --help`. See [Not covered by a skill](#not-covered-by-a-skill).\n7. **MUST NOT steer a local test run onto Testkube.** If the tests can just be run where the user is, say so, name the\n   plain command, and stop. This skill loads on generic \"run my tests\" phrasing precisely so it can rule Testkube\n   *out* as well as in.\n\n## Quick decision trees\n\n### \"Run my k6 / Playwright / e2e tests\" — is Testkube the right answer?\n\nStart here whenever the request is about running tests but never named Testkube. Testkube is not the answer to every\nsuch request, and saying so is a valid outcome.\n\n```\nWhere do these tests need to run?\n├── right here, once, on this machine\n│     └──► NOT Testkube. Run the framework directly — `npm test`, `npx playwright test`,\n│          `k6 run`, `pytest`, `mvn test`. Say so plainly and stop. Do not load\n│          another skill, do not author a workflow.\n│\n├── in a Kubernetes cluster, or against services only reachable from inside one\n├── on a schedule, or triggered by a cluster event (deploy, rollout)\n├── sharded, in parallel, or at load-test scale beyond one machine\n├── in CI, with logs, artifacts and JUnit results kept centrally\n└── identically for every engineer and every pipeline\n      └──► Testkube fits ──► see \"I want to run my tests with Testkube\" below\n```\n\nIf the request is genuinely ambiguous (\"run my e2e tests\" in a repo with a working local runner), **ask where they\nshould run before assuming Testkube.** A local test run needs no platform.\n\n### \"I want to run my tests with Testkube\"\n\n```\nIs the `testkube` command available?\n├── no  ──► installing-testkube-cli\n└── yes\n    │\n    Is there a Testkube environment to run against?\n    ├── no, and I want a local one  ──► installing-testkube-oss-agent\n    ├── no, and I want Cloud/on-prem ──► docs: /articles/install/overview\n    └── yes\n        │\n        Do I know what tests exist and what runs them?\n        ├── no  ──► test-discovery   (emits test-manifest.json)\n        └── yes\n            │\n            ──► testworkflow-author  (writes + validates workflow.yaml)\n            │\n            ──► testworkflow-runner  (runs it, diagnoses failures)\n```\n\n### \"I need a Testkube environment\"\n\n```\nLocal cluster, open source, CLI-driven, no dashboard\n  └──► installing-testkube-oss-agent\n\nTestkube Cloud or on-prem Control Plane (dashboard, multi-env, licensed runners)\n  └──► docs: /articles/install/overview, /articles/multi-agent-runner-helm-chart\n\nNot sure which one I need\n  └──► docs: /articles/install/feature-comparison\n```\n\n### \"My workflow failed\"\n\n```\n──► testworkflow-runner   reads logs, identifies root cause, reports exit code\n    │\n    ├── root cause is a workflow config problem (wrong image, missing step, bad command)\n    │     └──► hand the finding to testworkflow-author to fix the YAML, then re-run\n    │\n    ├── root cause is a real test assertion failure\n    │     └──► the workflow is fine; the tests found a bug\n    │\n    └── root cause is environment (agent down, no license, image pull)\n          └──► installing-testkube-oss-agent (local) or docs: /articles/install/overview\n```\n\n### \"I want tests to run automatically\"\n\n```\nOn a schedule                       ──► cron in the workflow spec: testworkflow-author\n                                        (see examples/cron-trigger.yaml)\nOn a Kubernetes event (deploy, etc) ──► TestTrigger — docs: /articles/test-triggers  [no skill]\nFrom a CI/CD pipeline               ──► docs: /articles/cicd-overview, /articles/github-actions  [no skill]\nFrom another workflow               ──► `execute` step: testworkflow-author\n                                        (see examples/suite-execute.yaml)\nOverview of every trigger mechanism ──► docs: /articles/triggering-overview\n```\n\n### \"I want to be notified when a test finishes\"\n\n```\nHTTP callback to an external system ──► Webhooks — docs: /articles/webhooks           [no skill]\nReusable webhook definition         ──► Webhook templates — docs: /articles/webhooks  [no skill]\nCDEvents / Kubernetes events        ──► docs: /articles/cd-events                     [no skill]\n```\n\n### \"I want to share setup across workflows\"\n\n```\n──► TestWorkflowTemplate — docs: /articles/test-workflow-templates, /articles/templates\n    │\n    ├── writing or consuming the template YAML  ──► testworkflow-author\n    │                                               (see examples/jmeter-template.yaml,\n    │                                                examples/step-level-use.yaml)\n    └── CRUD on templates in a live environment ──► `testkube create/get/delete testworkflowtemplate --help`\n```\n\n## Skill index\n\n| I need to...                                                              | Skill                           | Does NOT                                            |\n| ------------------------------------------------------------------------- | ------------------------------- | --------------------------------------------------- |\n| Install, upgrade, or verify the `testkube` CLI                            | `installing-testkube-cli`       | Deploy an agent or cluster                          |\n| Get a local OSS Testkube environment running                              | `installing-testkube-oss-agent` | Set up a Control Plane; install the CLI itself      |\n| Find out what tests a cloned repo has and what runs them                  | `test-discovery`                | Execute tests, install deps, or write YAML          |\n| Write or fix TestWorkflow / TestWorkflowTemplate YAML                     | `testworkflow-author`           | Run the workflow                                    |\n| Run a workflow, read logs, diagnose a failure                             | `testworkflow-runner`           | Edit workflow YAML                                  |\n| Anything else (webhooks, triggers, integrations, resource CRUD, RBAC)     | *none ships in this plugin*     | — see [Not covered by a skill](#not-covered-by-a-skill) |\n\nThe skills chain: `test-discovery` → `testworkflow-author` → `testworkflow-runner`, with the two `installing-*` skills\nas prerequisites. `installing-testkube-oss-agent` treats `installing-testkube-cli` as a **REQUIRED SUB-SKILL**.\n\n## Concept glossary\n\n**TestWorkflow** — the core resource (`apiVersion: testworkflows.testkube.io/v1`, `kind: TestWorkflow`). Declares\ncontent (git checkout or inline files), container image, and an ordered list of steps.\nSee https://docs.testkube.io/articles/test-workflows\n\n**TestWorkflowTemplate** — a reusable building block with the same schema shape (`kind: TestWorkflowTemplate`).\nWorkflows pull it in with `use` (top-level or step-level) or `template` (isolated). Templates cannot include other\ntemplates. See https://docs.testkube.io/articles/test-workflow-templates\n\n**TestWorkflowExecution** — one run of a workflow, with its own id, status, step results, logs, and artifacts. This is\nwhat `testkube run` produces and what `testkube get testworkflowexecution` reads.\n\n**Execution model** — Testkube creates a Kubernetes Job, which creates a Pod. Steps run as **sequential init\ncontainers**; the last step runs as the main container. All steps share the `/data` volume; git content lands in\n`/data/repo`. Job, Pod, and ConfigMaps are cleaned up afterward.\nSee https://docs.testkube.io/articles/test-workflows-high-level-architecture\n\n**Control Plane** — the central component (Testkube Cloud or on-prem) providing the dashboard, organizations,\nenvironments, and coordination of connected agents. Not present in OSS standalone.\n\n**Agent** — a Testkube deployment in a cluster that connects to a Control Plane. Since 2.7.0 an agent carries any\ncombination of four capabilities: **runner** (executes workflows — requires a license), **listener** (watches\nKubernetes events for TestTriggers), **gitops** (syncs resources from a namespace into the Control Plane), and\n**webhook** (emits webhooks, CDEvents, Kubernetes events).\nSee https://docs.testkube.io/articles/agents-overview\n\n**Standalone Agent** — the open-source single-cluster deployment. No Control Plane, no dashboard; driven from the CLI.\nSee https://docs.testkube.io/articles/install/standalone-agent\n\n**Organization / environment** — Control Plane scoping. An organization holds environments; each environment is a\nlogical boundary for workflows, executions, and connected agents.\n\n**TestTrigger** — a Kubernetes-event-driven rule (\"when this Deployment rolls, run that workflow\"). Defined by a\nYAML/JSON manifest, served by a listener agent. See https://docs.testkube.io/articles/test-triggers\n\n**Webhook / WebhookTemplate** — outbound HTTP notification on execution events (start-test, end-testworkflow, and\nfriends), with a custom payload; templates make the definition reusable.\nSee https://docs.testkube.io/articles/webhooks\n\n**Artifacts** — files collected from steps via `artifacts.paths` glob patterns, stored in MinIO or S3-compatible\nstorage. Testkube automatically scans `.xml` artifacts for JUnit reports.\nSee https://docs.testkube.io/articles/test-workflows-artifacts and\nhttps://docs.testkube.io/articles/test-workflows-reports\n\n**Expressions** — the `{{ }}` templating language available in most string fields: arithmetic, comparisons, string and\nJSON functions, `secret()`, `shellquote()`, plus built-ins like `execution.id`, `workflow.name`, `config.*`, `matrix.*`,\n`failed`, `passed`. See https://docs.testkube.io/articles/test-workflows-expressions\n\n**`Test` / `TestSuite` (legacy)** — the pre-TestWorkflow API. **Deprecated.** New work uses TestWorkflows.\nSee https://docs.testkube.io/articles/legacy-deprecation\n\n## Deployment topologies\n\nGetting this wrong is the most common source of confidently incorrect Testkube answers. Establish which topology is in\nplay before describing capabilities.\n\n| | **OSS standalone agent** | **Control Plane (Cloud / on-prem)** |\n| --- | --- | --- |\n| Dashboard | none — CLI only | yes |\n| Scope | one cluster, one namespace | many environments, many connected agents |\n| Auth | local kubeconfig / API URI | `testkube login`, org + environment context |\n| Runner agents | n/a | yes (licensed) |\n| Listener / GitOps / webhook agents | n/a | yes |\n| License | not required | required for licensed capabilities |\n| Set up with | `installing-testkube-oss-agent` | https://docs.testkube.io/articles/install/overview |\n\nFull matrix: https://docs.testkube.io/articles/install/feature-comparison\n\n## Docs index\n\nAll URLs below are under `https://docs.testkube.io`. This index is curated, not generated — if a link 404s, get the\ncurrent URL from https://docs.testkube.io/sitemap.xml rather than guessing a slug.\n\n**Start here**\n\n| Page | URL |\n| --- | --- |\n| Documentation home | https://docs.testkube.io/ |\n| Open source overview | https://docs.testkube.io/articles/open-source |\n| Quickstart (OSS) | https://docs.testkube.io/articles/getting-started-with-open-source |\n| Hands-on tutorial | https://docs.testkube.io/articles/tutorial/quickstart/overview |\n| Testkube for AI agents | https://docs.testkube.io/articles/ai-agents |\n\n**Install**\n\n| Page | URL |\n| --- | --- |\n| Install overview | https://docs.testkube.io/articles/install/overview |\n| Standalone agent (OSS) | https://docs.testkube.io/articles/install/standalone-agent |\n| Runner agent Helm chart | https://docs.testkube.io/articles/multi-agent-runner-helm-chart |\n| Install with Helm | https://docs.testkube.io/articles/install/install-with-helm |\n| Advanced install | https://docs.testkube.io/articles/install/advanced-install |\n| OSS vs Control Plane | https://docs.testkube.io/articles/install/feature-comparison |\n| MongoDB administration | https://docs.testkube.io/articles/mongodb-administration |\n\n**Concepts**\n\n| Page | URL |\n| --- | --- |\n| Testing pipeline | https://docs.testkube.io/articles/testing-pipeline |\n| Architecture | https://docs.testkube.io/articles/architecture |\n| Agents overview | https://docs.testkube.io/articles/agents-overview |\n| Agent CLI commands | https://docs.testkube.io/articles/multi-agent-cli |\n| Environment management | https://docs.testkube.io/articles/environment-management |\n| Using Testkube | https://docs.testkube.io/articles/using-testkube |\n\n**TestWorkflows**\n\n| Page | URL |\n| --- | --- |\n| Overview | https://docs.testkube.io/articles/test-workflows |\n| Creating | https://docs.testkube.io/articles/test-workflows-creating |\n| Running | https://docs.testkube.io/articles/test-workflows-running |\n| Execution architecture | https://docs.testkube.io/articles/test-workflows-high-level-architecture |\n| Templates | https://docs.testkube.io/articles/test-workflow-templates |\n| Official templates | https://docs.testkube.io/articles/templates |\n| Basic examples | https://docs.testkube.io/articles/test-workflows-examples-basics |\n| Content (git, files) | https://docs.testkube.io/articles/test-workflows-content |\n| Artifacts | https://docs.testkube.io/articles/test-workflows-artifacts |\n| Reports (JUnit) | https://docs.testkube.io/articles/test-workflows-reports |\n| Services | https://docs.testkube.io/articles/test-workflows-services |\n| Parallelization | https://docs.testkube.io/articles/test-workflows-parallel |\n| Matrix & sharding | https://docs.testkube.io/articles/test-workflows-matrix-and-sharding |\n| Expressions | https://docs.testkube.io/articles/test-workflows-expressions |\n| Step data sharing | https://docs.testkube.io/articles/test-workflows-step-sharing |\n| Suites (`execute`) | https://docs.testkube.io/articles/test-workflows-test-suites |\n\n**Automation & integrations**\n\n| Page | URL |\n| --- | --- |\n| Triggering overview | https://docs.testkube.io/articles/triggering-overview |\n| Test triggers | https://docs.testkube.io/articles/test-triggers |\n| Webhooks | https://docs.testkube.io/articles/webhooks |\n| CDEvents | https://docs.testkube.io/articles/cd-events |\n| GitOps | https://docs.testkube.io/articles/gitops-overview |\n| CI/CD overview | https://docs.testkube.io/articles/cicd-overview |\n| GitHub Actions | https://docs.testkube.io/articles/github-actions |\n| Integrations | https://docs.testkube.io/articles/integrations |\n| MCP server (preview) | https://docs.testkube.io/articles/mcp-overview |\n\n**Reference**\n\n| Page | URL |\n| --- | --- |\n| CLI reference | https://docs.testkube.io/cli/testkube |\n| OpenAPI / REST | https://docs.testkube.io/openapi/overview |\n| CRDs | https://docs.testkube.io/articles/crds |\n| Licensing | https://docs.testkube.io/articles/licensing |\n| Telemetry | https://docs.testkube.io/articles/telemetry |\n| Legacy deprecations | https://docs.testkube.io/articles/legacy-deprecation |\n| Logs & artifacts | https://docs.testkube.io/articles/logs-and-artifacts |\n| Examples & guides | https://docs.testkube.io/articles/examples/overview |\n| Changelog | https://docs.testkube.io/changelog |\n\n## CLI orientation\n\nLearn the shape of the CLI, then discover the details with `--help`. Do not recall flags.\n\nThe same binary is installed under three names — `testkube`, `tk`, and `kubectl-testkube` (invoked as\n`kubectl testkube`). Resolve it defensively before use:\n\n```bash\nTK_CMD=\"$(command -v testkube || command -v tk || command -v kubectl-testkube)\"\n[ -n \"$TK_CMD\" ] || echo \"Testkube CLI not found; use installing-testkube-cli\"\n```\n\nCommands follow `testkube <verb> <resource> [name] [flags]`:\n\n| Verb | Purpose |\n| --- | --- |\n| `create` | Create a resource, usually from `-f <file>`; `--update` upserts |\n| `get` | List resources, or show one by name |\n| `update` | Update an existing resource |\n| `delete` | Delete a resource |\n| `run` | Start a workflow execution (`-f` streams and blocks until terminal) |\n| `watch` | Follow a running execution |\n| `cancel` | Cancel executions |\n| `download` | Fetch artifacts from an execution |\n\nResource names and their aliases:\n\n| Resource | Aliases |\n| --- | --- |\n| `testworkflow` | `testworkflows`, `tw` |\n| `testworkflowexecution` | `testworkflowexecutions`, `twe`, `twexecution` |\n| `testworkflowtemplate` | `testworkflowtemplates`, `twt` |\n| `testtrigger` | `testtriggers`, `tt` |\n| `workflowtrigger` (v2) | `workflowtriggers`, `wt` |\n| `webhook` | `webhooks`, `wh` |\n| `webhooktemplate` | `webhooktemplates`, `wht` |\n\nContext and status:\n\n```bash\ntestkube version                 # CLI + server version, current context and namespace\ntestkube status                  # feature / resource status\ntestkube login                   # authenticate against a Control Plane\ntestkube set context --help      # switch org / environment / namespace\ntestkube dashboard               # open the dashboard (Control Plane only)\ntestkube --help                  # full verb list, including agent, mcp, debug, diagnostics\n```\n\nFull reference: https://docs.testkube.io/cli/testkube\n\n## Not covered by a skill\n\n**No skill in this plugin covers the tasks below.** Say so, then use the doc page and the `--help` output.\n\n| Task | Docs | CLI |\n| --- | --- | --- |\n| Webhooks | https://docs.testkube.io/articles/webhooks | `testkube create webhook --help` |\n| Webhook templates | https://docs.testkube.io/articles/webhooks | `testkube create webhooktemplate --help` |\n| Test triggers | https://docs.testkube.io/articles/test-triggers | `testkube create testtrigger --help` |\n| Workflow triggers (v2) | https://docs.testkube.io/articles/triggering-overview | `testkube create workflowtrigger --help` |\n| TestWorkflowTemplate CRUD | https://docs.testkube.io/articles/test-workflow-templates | `testkube create testworkflowtemplate --help` |\n| GitOps sync | https://docs.testkube.io/articles/gitops-overview | `testkube agent --help` |\n| CI/CD integration | https://docs.testkube.io/articles/cicd-overview | — |\n| Control Plane install | https://docs.testkube.io/articles/install/overview | `testkube init --help` |\n| Agents & runners | https://docs.testkube.io/articles/agents-overview | `testkube create runner --help` |\n| MCP server (preview) | https://docs.testkube.io/articles/mcp-overview | `testkube mcp --help` |\n| Licensing | https://docs.testkube.io/articles/licensing | — |\n\n## Gotchas\n\n- **Answering from memory** — pre-trained knowledge of Testkube is stale and biased toward the deprecated\n  `Test` / `TestSuite` API. Fetch the doc page or run `--help` before stating a fact.\n- **Recommending `kind: Test` or `testkube create test`** — that is the legacy API. New work uses `TestWorkflow`.\n- **Assuming a dashboard exists** — the OSS standalone agent has none. `testkube dashboard` is a Control Plane feature.\n- **Assuming runner / listener / gitops / webhook agents are available** — those are Control Plane capabilities, and\n  runner agents require a license. They do not exist in OSS standalone.\n- **Expecting sidecars in steps** — steps run as init containers, so operator-injected sidecars (Istio, Linkerd) are\n  not reachable from them. Container merging exists partly to mitigate this.\n- **Expecting a fresh filesystem per step** — steps in one pod share `/data`. Parallel workers do not: use\n  `transfer` / `fetch`.\n- **Guessing doc URLs** — `docs.testkube.io/...` and `testkube.io/docs/...` both resolve, but invented slugs 404.\n  Use the [Docs index](#docs-index) or search from https://docs.testkube.io/.\n- **Doing the specialist skill's job** — if the request is \"write this workflow\" or \"run and debug this\", stop routing\n  and hand off. This skill produces orientation, not artifacts.\n- **Answering \"run my tests\" with Kubernetes** — this skill loads on generic test-running phrasing, so it will\n  sometimes load when the right answer is `npm test`. Give that answer. Reaching for a cluster the user never asked\n  for costs them an install and buys them nothing.\n"
}