verify-live-prod-before-shipping-superseded-fix

Verifies live production state before deploying fixes that parallel sessions may have superseded.

3|Updated May 8, 2026
One-click install
npx skills add https://github.com/wan-huiyan/agent-traffic-control --skill verify-live-prod-before-shipping-superseded-fix-wan-huiyan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: verify-live-prod-before-shipping-superseded-fix
Source: https://github.com/wan-huiyan/agent-traffic-control/tree/main/plugins/agent-traffic-control/skills/verify-live-prod-before-shipping-superseded-fix
Command: npx skills add https://github.com/wan-huiyan/agent-traffic-control --skill verify-live-prod-before-shipping-superseded-fix-wan-huiyan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? In multi-session workflows, a parallel Claude session can ship a different fix for the same issue to the same shared production artifact while you are mid-build, making your completed work redundant and risking a deploy that clobbers the live fix. Handoffs and open issues reflect the world when they were written, not the current deployed state. ## Core Features & Use Cases - Start-of-task live-state verification: Probe the deployed artifact (compile the live Dataform release config, read the deployed file or config) before investing in a full implementation. - Pre-deploy re-verification: Re-check the live state immediately before any deploy to a shared prod artifact, since a parallel session can ship between your build and your deploy. - Supersession handling: Stand down without deploying, preserve your analysis as a branch, reconcile open issues, and clean up isolated validation infrastructure. - Assessment variant: For verdict-only deliverables, pin the base SHA at assessment start and diff it against origin/main before publishing the verdict. - Use Case: You pick up a handoff to ship a scoped fix to a Dataform .sqlx, notice a sibling issue mysteriously closed, compile the live release config, find another session's fix already deployed, and stand down instead of clobbering it. ## Quick Start Before building or deploying a fix to a shared production artifact, verify the live deployed state of the target and check whether any sibling issues or PRs already resolved the same issue.

Frequently Asked Questions about verify-live-prod-before-shipping-superseded-fix

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

FAQPage Schema
How do I avoid deploying a fix that another session already shipped?▼

Verify the live deployed state of the target artifact at task start and again immediately before deploying. Compile the live release config or read the deployed file and grep for the markers your fix would add, rather than trusting the handoff or issue status.

Why is an open GitHub issue not proof a bug is unfixed?▼

An issue reflects the world when it was written; a parallel session can ship a fix while the issue stays open. A sibling issue closing unexpectedly is an early signal, so inspect it with gh issue view and search related PRs with gh pr list.

What should I do when my completed fix is superseded by a parallel session?▼

Stand down and do not deploy over the live fix. Push your branch to preserve the analysis, comment the supersession on the open issue, file any residual findings the live fix did not cover, and clean up isolated validation infrastructure.

How do I keep a deployment assessment verdict from going stale?▼

Pin the base SHA with git rev-parse origin/main at assessment start, then fetch and run git log BASE..origin/main immediately before publishing the verdict. Re-check only the claims whose inputs those intervening commits could have moved.

When is it safe to deploy over a live fix from another session?▼

Only via an atomic revert-and-swap, and only when your approach is strictly better on a dimension the live fix lacks. Blind-deploying over a shared prod file risks clobbering the working fix with two mechanisms on one artifact.