pilot-release-verification

Verify post-deploy Kubernetes/GitOps releases against declared intent using cub-scout evidence.

14|Updated Jan 17, 2026

Search Tags:#kubernetes #receipts #gitops #attribution #release verification #three-way compare #source truth

Ready to run

npx skills add https://github.com/confighub/cub-scout --skill pilot-release-verification

💬 Prompt for ChatGPT / Claude Chat▼

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It confirms whether a Kubernetes/GitOps release actually landed cleanly after the deploy has completed, instead of assuming reconciliation finished successfully.

Core Features & Use Cases

Post-deploy convergence verdicts: Uses cub-scout evidence to judge DRY/WET/LIVE convergence per resource, producing a release-quality outcome.
Source-truth attribution to the release SHA: Pins evaluation to the intended revision with --at-commit so the verdict matches the declared release, not a later drift.
Timeline and drift context: Uses history since the deploy time to detect surprise changes during the deployment window.
Release-level rollup and routing: Maps resource outcomes (agreed/converging/diverged) into clear PASS/WATCH/BLOCK/ASK actions, and defers rollback decisions to the rollback skill.

Quick Start

Pilot, verify the release by checking convergence and source-truth against the release SHA after the deploy settles.

Frequently Asked Questions about pilot-release-verification

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

FAQPage Schema

How do I verify a Kubernetes GitOps release actually landed after deployment?▼

To verify a Kubernetes GitOps release landed, you need a post-deploy convergence check using a three-way compare with source-truth attribution pinned to the release SHA, producing a clear release-level verdict.

What is source-truth attribution pinned to a release SHA in GitOps verification?▼

Source-truth attribution in GitOps verification pins the evaluation to the intended revision using a specific commit SHA, ensuring the release verdict matches the declared release rather than reflecting a later drift.

Does release verification work with Argo CD, Flux, Helm, and Crossplane reconciliation?▼

Yes, post-deploy release verification works across Argo CD, Flux, Helm, and Crossplane, checking whether reconciliation finished successfully in after-the-fact confirmation scenarios where reconciliation may still be in flight.

How do I check for configuration drift during a Kubernetes deployment window?▼

You can check for configuration drift during a Kubernetes deployment window by analyzing timeline history since the deploy time, detecting surprise changes and mapping resource outcomes into agreed, converging, or diverged states.

What is the difference between DRY, WET, and LIVE convergence in release verification?▼

DRY, WET, and LIVE convergence in release verification judge the state of each resource using cub-scout evidence, comparing declared intent against the live Kubernetes cluster to produce a release-quality outcome.

Why does my GitOps release show successful deployment but resources are still diverging?▼

Resources can still diverge after a successful GitOps deployment because reconciliation may still be in flight, requiring a post-deploy convergence verdict and timeline history check to detect surprise changes during the deployment window.