gke-workload-troubleshooting skillA
gke-workload-troubleshooting is agent-read markdown (skill) from gke-labs/kube-agents: Systematic Standard Operating Procedure (SOP) for diagnosing GKE workload failures, crash loops, resource OOMs, mounting errors, and connectivity timeouts..
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
# GKE Workload Troubleshooting Skill Use this skill to systematically diagnose and resolve failures in application workloads deployed in GKE clusters. This skill enforces a read-only diagnostics boundary before proposing manifest or config corrections. ## 🔍 Diagnostic Workflow ### Step 0: Context Acquisition & Time Window Definition To begin troubleshooting, acquire the following context from the user or active `SETTINGS.md` config: - **Project ID** (e.g., `my-gcp-project`) - **Cluster Name** (e.g., `my-gke-cluster`) - **Cluster Location** (e.g., `us-central1`) - **Workload Name** (e.g., `payment-api`) - **Workload Namespace** (e.g., `checkout`) - **Issue Time** (Optional, e.g., `2026-06-01T15:30:00Z`) Before running any diagnostics or `kubectl` commands, you **must** fetch GKE credentials and context for the target GKE cluster: ```bash gcloud container clusters get-credentials <cluster_name> --region <cluster_location> ``` #### Time Handling & Fallbacks: 1. **Determine Issue Timestamp ($T$)**: - **Specific Time Provided**: If the user provides a specific timestamp, use it as $T$. …
Read the whole file at its exact version.
How to install
mdr add gke-labs/kube-agents/gke-workload-troubleshooting@git:20260909.eb89697mdr add gke-labs/kube-agents/gke-workload-troubleshooting@sha256:2dd153440aa9e119Pin 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_iw4ag2dhz364eqdz)
1 badge views in 30 days
Versions
| version | committed | commit | size | audit | |
|---|---|---|---|---|---|
| git:20260909.eb89697 latest | 2026-09-09 | eb89697 | 9,648 B | A | view · diff |
| git:20260904.e20318d | 2026-09-04 | e20318d | 9,482 B | A | view · diff |
| git:20260821.10730d8 | 2026-08-21 | 10730d8 | 9,472 B | A | view · diff |
| git:20260812.8e8a46c | 2026-08-12 | 8e8a46c | 9,294 B | A | view · diff |
| git:20260728.aca5b5c | 2026-07-28 | aca5b5c | 9,025 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 (9648 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_iw4ag2dhz364eqdz GET https://markdownregistry.com/api/v1/resolve?ref=gke-labs/kube-agents/gke-workload-troubleshooting GET https://markdownregistry.com/api/v1/blob/2dd153440aa9e119b17107d9dbbf4a2de04149675aef0894527647a0989023c0
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.
More from gke-labs/kube-agents
Every file in gke-labs/kube-agents