pilot-rollback-decision

Evaluate ConfigHub history and receipts to select the safest Kubernetes rollback revision.

14|Updated Jan 17, 2026

Search Tags:#rollback #kubernetes #gitops #confighub #receipt verify #safety verdict

Ready to run

npx skills add https://github.com/confighub/cub-scout --skill pilot-rollback-decision

💬 Prompt for ChatGPT / Claude Chat▼

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you decide whether to roll back a broken Kubernetes release and which prior revision is safest to target.

Core Features & Use Cases

Rollback target safety verdicts: Evaluates candidate prior revisions with receipt verify --at-commit, producing PASS/WATCH/BLOCK/INCONCLUSIVE guidance.
Evidence-backed decisioning: Uses ConfigHub history (ChangeSet timeline) plus impact (blast-radius preview) and receipt data to explain why a rollback target is chosen.
Decision chain for auditability: Optionally chains per-candidate receipts into a chosen-target receipt via --input-attestation, preserving the full evaluation rationale.

Quick Start

Ask the AI to produce a rollback verdict for Deployment/payments-api in prod by evaluating candidate revisions from history and selecting the most-recent PASS target.

Frequently Asked Questions about pilot-rollback-decision

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

FAQPage Schema

How do I decide which Kubernetes revision is safest to roll back to after a broken release?▼

To determine the safest Kubernetes rollback target, evaluate candidate prior revisions using receipt verification and blast-radius impact analysis. This produces a structured safety verdict—PASS, WATCH, BLOCK, or INCONCLUSIVE—for each candidate, identifying the most recent revision that passed verification.

What is a rollback safety verdict and how does it work with GitOps?▼

A rollback safety verdict is a structured assessment that determines if a prior Kubernetes revision is safe to restore. It works by verifying revision-pinned receipts at each candidate commit and analyzing ConfigHub history to produce auditable PASS or BLOCK guidance for GitOps operations.

How do I evaluate blast-radius impact before rolling back a Kubernetes deployment?▼

Evaluating blast-radius impact before a Kubernetes rollback involves previewing the potential effect of reverting to a candidate revision. By analyzing ConfigHub history and impact data alongside per-candidate receipts, you receive evidence-backed guidance on whether a target is safe or should be blocked.

Can I audit the decision chain when choosing a rollback target in Kubernetes?▼

Yes, you can audit the rollback decision chain by chaining per-candidate evaluation receipts into a final chosen-target receipt. Using input attestation preserves the full safety verdict rationale, ensuring the evidence behind a Kubernetes rollback target is completely traceable for post-incident reviews.

Do I need ConfigHub connected-mode capabilities to verify Kubernetes rollback candidates?▼

Yes, generating rollback safety verdicts requires ConfigHub connected-mode capabilities for history and impact analysis. These features enable the ChangeSet timeline review and blast-radius preview necessary to evaluate candidate revisions and produce a verified rollback target receipt.

When should I not use an automated rollback target decision for my Kubernetes deployment?▼

You should avoid automated rollback target decisions when verification results are INCONCLUSIVE or BLOCK. If candidate revisions fail receipt verification or the blast-radius impact is unacceptable, the system prevents a rollback, requiring manual investigation before reverting the broken Kubernetes release.