k8s-triage

Diagnose unhealthy Kubernetes workloads by analyzing cluster context and logs.

Updated May 19, 2026
One-click install
npx skills add https://github.com/blouargant/yoke-registry --skill k8s-triage
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: k8s-triage
Source: https://github.com/blouargant/yoke-registry/tree/main/skills/DevOps/k8s-triage
Command: npx skills add https://github.com/blouargant/yoke-registry --skill k8s-triage

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you quickly identify why a Kubernetes workload is unhealthy by organizing evidence from deployments, pods, events, and logs into a clear failure category.

Core Features & Use Cases

  • Evidence-first Kubernetes incident triage: Captures cluster context, workload state, unhealthy pod details, prior logs, and recent events to ground the diagnosis.
  • Failure classification for next-step guidance: Categorizes issues into image/pull, scheduling, probe, configuration, network, permission, or application crash behavior.
  • Safety and production guardrails: Enforces rules that prevent destructive actions like delete without explicit confirmation and avoids production namespace modifications without override.
  • Targeted escalation to specialized debug flow: If the issue appears to be application crashes or configuration, it routes toward a deeper debugging skill for actionable next steps.

Quick Start

Use the k8s-triage skill when you see kubectl or Kubernetes symptoms by asking for a triage plan for the affected namespace and workload, e.g., "Diagnose why my Kubernetes deployment is unhealthy in namespace staging and recommend the single next action."

Frequently Asked Questions about k8s-triage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose Kubernetes pods stuck in CrashLoopBackOff?

To diagnose Kubernetes pods stuck in CrashLoopBackOff, gather and analyze cluster context, unhealthy pod details, recent events, and prior logs to classify the failure into categories like image/pull, probe, or application crash, then apply a safe next action.

What is the best way to triage failing Kubernetes workloads across namespaces?

Triage failing Kubernetes workloads across namespaces by executing read-only kubectl investigation to capture workload state and events, classifying the failure into image, scheduling, probe, network, permission, or application categories to pinpoint the root cause.

Why is my Kubernetes deployment not ready and how do I find the failure category?

Find why a Kubernetes deployment is not ready by collecting evidence from deployments, pods, events, and logs to classify the issue into image/pull, scheduling, probe, configuration, network, permission, or application crash behavior.

Can I run kubectl triage commands safely in a production namespace?

You can run read-only kubectl triage safely in production, but the workflow enforces guardrails that prevent destructive actions like delete without explicit confirmation and avoids production namespace modifications without override.

What should I do after kubectl triage identifies an application crash or configuration error?

After kubectl triage identifies an application crash or configuration error, it routes you toward a deeper debugging skill for actionable next steps and proposes exactly one safe next action with dry-run preference when possible.