observe-crossplane

Classify Kubernetes resources as Crossplane-managed using labels and ownerReferences.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps users understand why a Kubernetes resource exists and who (Crossplane) owns each field, by connecting Crossplane signals like XR/Claim/Composition production, managed-child composition hashes, and controller-managedFields evidence.

Core Features & Use Cases

  • Crossplane-specific attribution: Identify whether the resource is a Crossplane control-plane object (XRDs/Compositions/Providers) or a managed workload produced from a Composite/Claim path.
  • Trace XR/Claim ↔ composed children: Explain which XR/Claim/Composition produced the resource and what the composed-<hash> manager implies.
  • ProviderConfig secret evidence: Surface whether ProviderConfig credential secrets are present, missing, unreadable, or unresolved during trace output.

Use case: When you find an unhealthy workload, ask for Crossplane ownership and get a precise explanation of which XR/Claim/Composition produced it and which managedFields managers account for controller-driven changes.

Quick Start

Ask observe-crossplane to explain whether bucket/my-bucket is managed by Crossplane and trace it back to the originating Claim and Composition.

Frequently Asked Questions about observe-crossplane

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

FAQPage Schema
How do I tell if a Kubernetes resource is owned by Crossplane?

Crossplane ownership is classified by checking for crossplane.io labels and falling back to ownerReference data. This ownership attribution identifies whether a resource is a Crossplane control-plane object or a managed workload produced from a Composite or Claim path.

Why does my Crossplane managed resource have a composed hash in managedFields?

A composed-<hash> manager prefix in managedFields indicates a composed child resource matched to its parent. This signal explains which XR, Claim, or Composition produced the resource and accounts for controller-driven changes on that specific managed workload.

How do I trace an unhealthy Crossplane workload back to its originating Claim and Composition?

You trace Crossplane workloads by attributing resource fields to specific XR, Claim, and Composition production signals. This explains which Composition produced the unhealthy resource and which managedFields managers account for its controller-driven changes.

Can I check ProviderConfig credential secrets when diagnosing Crossplane drift?

ProviderConfig credential secrets are surfaced during trace output to show whether they are present, missing, unreadable, or unresolved. This credential evidence helps diagnose why a Crossplane managed resource might be unhealthy or drifting from its desired state.

How does Crossplane ownership attribution explain field-level drift on Kubernetes resources?

Field-level drift is explained by attributing individual resource fields to specific XR, Claim, and Composition production signals using known managedFields manager strings. This pinpoints exactly which Crossplane controllers account for detected changes on the resource.