cub-scout

Route Kubernetes and GitOps observability questions to the appropriate scout-* skill.

14|Updated Jan 17, 2026
One-click install
npx skills add https://github.com/confighub/cub-scout --skill cub-scout
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: cub-scout
Source: https://github.com/confighub/cub-scout/tree/main/skills/cub-scout
Command: npx skills add https://github.com/confighub/cub-scout --skill cub-scout

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It helps you understand what is currently happening in a live Kubernetes cluster and GitOps setup—what owns each value, what is unhealthy, and what to check next—without modifying anything.

Core Features & Use Cases

  • Read-only observer with attribution: Explain where field values come from (controller, git source, bindings, or manual edits) and why mismatches exist.
  • Intended vs live comparisons: Compare governed intent (when connected) against running reality to find drift and outliers.
  • Capability routing for questions: Acts as an umbrella router that sends you to the correct verb-group skill (observe, diagnose, compare, attribute, govern, ingest/adopt, integrate via MCP, verify).

Quick Start

Ask the assistant: "Can cub-scout explain what owns this resource and why it's unhealthy, and is there drift versus intended state?"

Frequently Asked Questions about cub-scout

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

FAQPage Schema
How do I detect drift in a live Kubernetes cluster without modifying resources?

You can detect drift by comparing governed GitOps intent against the live Kubernetes cluster reality to find mismatches and outliers. This read-only approach identifies where field values originate and why they differ without modifying resources.

What is the best way to trace Kubernetes field attribution back to controllers or git sources?

Tracing Kubernetes field attribution requires a read-only observer that explains whether values originate from controllers, git sources, bindings, or manual edits. This identifies ownership and clarifies why mismatches exist in live cluster state.

Can I compare intended GitOps state against a live Kubernetes cluster safely?

Yes, comparing intended GitOps state against a live Kubernetes cluster is safe using read-only behavior. This comparison identifies drift and outliers without mutating the live cluster or altering GitOps configuration.

Does read-only Kubernetes observability work offline without connecting to ConfigHub?

Read-only Kubernetes observability enforces offline-safe behavior by default, functioning without connecting to ConfigHub. Without the connection, it observes and attributes live cluster values but cannot compare against governed intent.

Why does my Kubernetes resource show unhealthy status and how do I find what owns it?

Diagnosing unhealthy Kubernetes resources involves attributing field ownership to controllers, git sources, bindings, or manual edits. The read-only observer determines what owns each value and explains why the resource is unhealthy without applying fixes.