pilot-patch-and-drift

Classify Kubernetes intended-versus-live drift using cub-scout attribution evidence.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Pilot needs to decide how to respond when intended (governed) Kubernetes state diverges from live cluster state, and it must choose the right action based on who/what caused the field change rather than guesswork.

Core Features & Use Cases

  • Deterministic drift evidence intake: Uses cub-scout’s structured field attribution outputs (cause, managerHint, gitSource, and optional bindingSource) to classify drift deterministically.
  • Decision support for policy actions: Helps Pilot determine whether to ACCEPT, REVERT, QUARANTINE, ACCEPT-AS-CANONICAL, or ASK a human based on the evidence.
  • Drift loop fit & safety boundary: Provides classification and recommendations only; it explicitly avoids being used for discovery or any mutating/reconciliation path performed outside cub-scout.

Quick Start

Ask Pilot to classify the drift on a specific Deployment field by reading cub-scout three-way compare evidence and returning an action verdict for the audit or next workflow step.

Frequently Asked Questions about pilot-patch-and-drift

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

FAQPage Schema
How do I classify Kubernetes drift to decide whether to revert or accept live state changes?

Classifying Kubernetes drift requires structured field attribution evidence like cause, managerHint, and gitSource to deterministically recommend an action such as revert, quarantine, accept-as-canonical, or ask-human.

What is field-level divergence in Kubernetes GitOps and how does attribution work?

Field-level divergence in Kubernetes GitOps occurs when intended governed state differs from live cluster state. Attribution works by using structured compare outputs to identify the exact cause and manager of the specific field change.

How do I determine the correct patch policy action when ArgoCD or Flux managed fields drift?

Determining the correct patch policy action for ArgoCD or Flux drift involves reading structured three-way compare evidence to evaluate the cause and managerHint, returning a deterministic action verdict for the next workflow step.

Can I use this drift classification approach for automatic reconciliation or state mutation?

No, this drift classification approach explicitly avoids being used for discovery or any mutating and reconciliation paths. It provides classification and recommendations only, strictly operating as a read-only attribution-based decision support tool.

Do I need cub-scout compare output to classify Kubernetes intended-versus-live drift?

Yes, you need cub-scout compare output containing cause, managerHint, and gitSource to classify Kubernetes intended-versus-live drift. Optional bindingSource can also be used to ensure deterministic, read-only attribution-based recommendations.