shipping-and-launch

Verify acceptance criteria and evidence to produce a launchReadinessPlan.

Updated Apr 27, 2026
One-click install
npx skills add https://github.com/vTRKA/supervibe --skill shipping-and-launch-vtrka
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: shipping-and-launch
Source: https://github.com/vTRKA/supervibe/tree/main/skills/shipping-and-launch
Command: npx skills add https://github.com/vTRKA/supervibe --skill shipping-and-launch-vtrka

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Shipping changes without clear, command-backed evidence makes it hard to prove launch readiness, coordinate rollout/rollback, and support users after release.

Core Features & Use Cases

  • Launch readiness proof: Collect acceptance and targeted verification evidence across version/package surfaces, docs, changelog, and migration needs.
  • Operational rollout planning: Define rollout strategy (all-at-once, canary, staged, dark launch) and the conditions required for safe progression.
  • Rollback, monitoring, and support ownership: Specify rollback actions, monitoring metrics/alerts/smoke checks, communication, and post-launch cleanup to prevent “merge-event” style releases.

Quick Start

Ask your AI to run a release gate in dry-run mode by providing the change scope, acceptance criteria, target branch/version, and authority, and to return a structured launchReadinessPlan with a BLOCK/ADVISORY/RELEASE decision.

Frequently Asked Questions about shipping-and-launch

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

FAQPage Schema
How do I prove release readiness with evidence before a production rollout?

You can verify release readiness by checking project scope, git state, version and changelog alignment, and defining rollback actions. This returns a structured launchReadinessPlan that scores confidence against a gate, providing a clear BLOCK, ADVISORY, or RELEASE decision for your production rollout.

What is the best way to plan a feature rollout and define rollback conditions?

Defining a feature rollout involves selecting a strategy like canary, staged, or dark launch, and specifying conditions for safe progression. You also define rollback actions, monitoring metrics, alerts, and post-launch cleanup to prevent uncontrolled merge-event style releases.

How do I check if my changelog, docs, and migration plan are aligned for a package publish?

Checking alignment for a package publish requires verifying targeted evidence across code graph release surfaces, git state, version, docs, and changelog. The process evaluates this alignment alongside migration needs to determine if the package update is truly ready to release.

Does this release readiness process support feature flags and dark launches?

Yes, the release readiness process supports feature flags and dark launches by allowing you to define specific rollout strategies and conditions required for safe progression. It evaluates your change scope and monitoring setup to return a structured launchReadinessPlan for these deployment methods.

How do I assign support ownership and communication for post-launch cleanup?

You assign support ownership and define communication by specifying post-launch cleanup actions as part of your launch readiness plan. This ensures operational changes, support responsibilities, and monitoring alerts are explicitly documented to prevent merge-event style releases.