manage-cluster skillA
manage-cluster is agent-read markdown (skill) from gke-labs/kube-agents: Bring an existing GKE cluster under management on user request (e.g. "manage my cluster <name> in <location>") by creating its Cluster Agent profile. Use whenever a user asks to manage/onboard/watch a specific existing cluster..
Indexed from public GitHub and served as immutable, content-addressed versions. Install it pinned to an exact SHA-256 with the mdr CLI, and every file is verified against the hash recorded here before it reaches your agent. The deterministic audit below grades the latest version, and the same file always earns the same grade.
What the file says
# Manage Cluster Skill
When a user asks you to **manage** (onboard / start watching) a specific existing GKE cluster — e.g. _"manage my cluster `payments-prod` in `us-central1`"_ — bring it under management by creating its **Cluster Agent profile**. After this, the cluster gets a per-cluster agent and is delegable via the kanban board.
This is the explicit, user-driven counterpart to onboarding-time creation (`gke-cluster-creation`). It is safe to run repeatedly (idempotent).
## Steps
1. **Gather the target.** You need `project`, `cluster`, and `location`.
- Use any values the user gave. If the user omits the **project**, resolve it:
- default to the platform's active project: `gcloud config get-value project`; then
- confirm the cluster exists in that project (next step). If it isn't there, or the name is ambiguous, run `gcloud container clusters list --format="value(name,location,resourceLabels)"` (optionally `--project <p>`) to locate it, and ask the user only if still ambiguous.
2. **Verify the cluster exists** before creating a profile (clean error instead of a half-scaffold):
…Read the whole file at its exact version.
How to install
mdr add gke-labs/kube-agents/manage-cluster@git:20260923.0dcc0b4mdr add gke-labs/kube-agents/manage-cluster@sha256:2f68a9cfbbd3e0eePin to a label to follow the author's releases, or to a sha256 to freeze the exact bytes forever. Either way the resolved hash is written to mdr.lock, and mdr install reproduces it on any machine.
[](https://markdownregistry.com/a/art_4jroeybxradnh27p)
1 badge views in 30 days
Versions
| version | committed | commit | size | audit | |
|---|---|---|---|---|---|
| git:20260923.0dcc0b4 latest | 2026-09-23 | 0dcc0b4 | 3,532 B | A | view · diff |
| git:20260820.e0ddc12 | 2026-08-20 | e0ddc12 | 3,380 B | A | view · diff |
| git:20260807.d47bdf1 | 2026-08-07 | d47bdf1 | 3,404 B | A | view · diff |
| git:20260728.aca5b5c | 2026-07-28 | aca5b5c | 3,404 B | A | view |
Audit of the latest version
- pass: Frontmatter block present
- pass: Frontmatter declares a name
- pass: Frontmatter declares a description
- pass: Size between 200 bytes and 200 KB (3532 bytes)
- pass: No zero-width or bidi control characters
- pass: No instruction hidden inside an HTML comment
- pass: No link to an exfiltration or paste host
- pass: No credential-shaped string
- pass: No instruction to send local credentials anywhere
- pass: No text hidden with inline styles
- pass: No prompt-injection phrasing
- pass: No curl or wget piped into a shell
- pass: No recursive delete of root, home or parent
- pass: No instruction to read or print local credentials
- pass: No base64 blob over 200 characters
- pass: No link to a raw IP address
- pass: No script tag
Source
gke-labs/kube-agents · 64 stars · license Apache-2.0 · pushed 2026-09-23 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_4jroeybxradnh27p GET https://markdownregistry.com/api/v1/resolve?ref=gke-labs/kube-agents/manage-cluster GET https://markdownregistry.com/api/v1/blob/2f68a9cfbbd3e0ee8c5f39a7f48b7804e5fd88dd6c9f4bcc3f7f3fc550d0fb4b
Your agent does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.