observe-native

Classify Kubernetes resource ownership via ownerReferences and managedFields signals.

14|Updated Jan 17, 2026

Search Tags:#kubernetes #orphan detection #gitops drift #ownership attribution #read-only diagnostics #ownerreferences #kubectl-applied

Ready to run

npx skills add https://github.com/confighub/cub-scout --skill observe-native

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: observe-native
Source: https://github.com/confighub/cub-scout/tree/main/skills/observe-native
Command: npx skills add https://github.com/confighub/cub-scout --skill observe-native

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you determine why Kubernetes resources appear native or unowned, so you can understand what that implies for ownership and next steps.

Core Features & Use Cases

Native vs unowned classification: Explains whether a resource is part of a native Kubernetes owner chain (via ownerReferences) or truly unowned (no GitOps/controller signals).
OwnerReferences-only meaning: Interprets Kubernetes-native ownership where built-in controllers reconcile child resources.
Orphan and drift context: Clarifies why OwnerType=unknown is an honest outcome and how to interpret it when controllers disappear or labels/managed fields are stripped.

Quick Start

Use observe-native to analyze the resource status and explain its ownership classification for a native or unowned Kubernetes object in your cluster.

Frequently Asked Questions about observe-native

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

FAQPage Schema

How do I determine if a Kubernetes resource is native or unowned?▼

To determine if a Kubernetes resource is native or unowned, analyze its ownerReferences and managedFields. Native resources rely on built-in controller chains via ownerReferences, while unowned resources lack any GitOps or controller signals, resulting in an unknown ownership classification for read-only diagnosis.

What does OwnerType=unknown mean for orphaned Kubernetes workloads?▼

OwnerType=unknown for orphaned Kubernetes workloads is an honest outcome indicating that no GitOps, Helm, or built-in controller signals were detected. It means the controller disappeared or labels and managed fields were stripped, preventing definitive ownership attribution during diagnostics.

How do I check ownership for kubectl-applied resources with no controller?▼

To check ownership for kubectl-applied resources with no controller, inspect the resource's managedFields and interactive writers. This Skill uses those read-only ownership detection signals to produce an evidence-based attribution result, classifying the resource appropriately when standard controller frameworks are absent.

Can I diagnose Kubernetes resource ownership without modifying the cluster?▼

Yes, you can diagnose Kubernetes resource ownership without modifying the cluster. This Skill satisfies read-only execution by relying solely on ownership detection signals like ownerReferences and managedFields to produce a safe, evidence-based attribution result for native or unowned resources.

Why does my Kubernetes resource show OwnerType=k8s instead of unknown?▼

Your Kubernetes resource shows OwnerType=k8s instead of unknown because built-in controllers are actively reconciling it through native ownerReferences. This distinguishes resources with active Kubernetes-native ownership chains from truly unowned resources where controllers have disappeared or signals were stripped.

When should I use observe-native for Kubernetes resource attribution?▼

Use observe-native for Kubernetes resource attribution when you need to explain unowned or native resources outside GitOps, Helm, Crossplane, kro, or ConfigHub management. It is ideal for diagnosing orphan workloads, kubectl-applied resources, and interpreting OwnerReferences-only ownership chains safely.