verify-apply

Classify post-apply outcomes by correlating unit status and runtime state across ConfigHub, controller, and cluster.

2|2|Updated Apr 15, 2026

Search Tags:#kubectl #argocd #flux #confighub #verify-apply #unit-status #post-apply

Ready to run

npx skills add https://github.com/confighub/confighub-skills --skill verify-apply

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: verify-apply
Source: https://github.com/confighub/confighub-skills/tree/main/skills/verify-apply
Command: npx skills add https://github.com/confighub/confighub-skills --skill verify-apply

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill helps operators determine whether a recent apply converged across ConfigHub, the controller, and the cluster, surfacing the first failure if any.

Core Features & Use Cases

Cross-layer verification: reads unit status and latest events to classify the post-apply arc (Progressing / Completed / Failed / Aborted).
Root-cause drilling: inspects cub unit-event get for per-resource statuses and the Message field, and cross-checks with kubectl, argocd, and flux to locate the failure.
Reporting & hand-off: optionally presents a three-way agreement table and revision history for close-out; does not mutate.

Quick Start

Run cub unit get <slug> --space <s> to inspect UnitStatus and LatestUnitEvent, then review the LatestUnitEvent Message for errors.

Frequently Asked Questions about verify-apply

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

FAQPage Schema

How do I verify a post-apply deployment converged across ConfigHub, ArgoCD, and the cluster?▼

Post-apply verification correlates unit status, latest events, and runtime state across ConfigHub, the controller, and the cluster to classify the deployment outcome as Progressing, Completed, Failed, or Aborted.

Why does my ConfigHub deployment show pending or failed after a recent apply?▼

A failed or pending deployment is diagnosed by inspecting the LatestUnitEvent Message and per-resource statuses via cub unit-event get, then cross-checking runtime state with kubectl, argocd, and flux to locate the failure.

How do I find the root cause of a failed post-apply run in ConfigHub?▼

Root-cause drilling inspects cub unit-event get for per-resource statuses and the Message field, cross-referencing with kubectl, argocd, and flux outputs to identify whether the issue originates in ConfigHub, the controller, or the cluster.

Can I use kubectl, argocd, and flux together to check post-deploy status without altering resources?▼

Yes, post-deploy verification performs non-mutating checks only, reading unit status and runtime state across kubectl, argocd, and flux to surface the first failure without applying or altering resources.

What's the best way to confirm three-way agreement between ConfigHub, the controller, and the cluster after an apply?▼

Cross-layer verification reads unit status and latest events to optionally present a three-way agreement table and revision history for close-out, confirming alignment across ConfigHub, the controller, and the cluster.

Does verify-apply require access to specific CLI tools to inspect post-deploy state?▼

Post-deploy verification requires access to cub unit get, cub unit-event get, kubectl, argocd, and flux commands to perform non-mutating checks that classify the post-apply arc and locate failures.