deploy-ship

Verify pre-deployment gates and post-deploy SLO health for production releases.

1|Updated Jul 9, 2026
One-click install
npx skills add https://github.com/PiercingXX/xx-stack --skill deploy-ship-piercingxx
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: deploy-ship
Source: https://github.com/PiercingXX/xx-stack/tree/main/runtime/skills/deploy-ship
Command: npx skills add https://github.com/PiercingXX/xx-stack --skill deploy-ship-piercingxx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents risky or incomplete production releases by forcing a repeatable deployment checklist that verifies tests, build/artifacts, changed scope, and post-deploy health.

Core Features & Use Cases

  • Pre-deployment readiness checks: validates deterministic gates first, then confirms build/artifact readiness and assesses change size/scope via git diff/log review.
  • Deployment execution within repo-supported paths: ensures release steps are only taken when the repo surface explicitly supports them, avoiding invented deploy routes.
  • Post-deploy health verification with an SLO smoke window: monitors error rate, latency, throughput stability, and auth success to decide whether to continue monitoring or trigger rollback.

Quick Start

Tell the skill to run the production release checklist for this repository and produce a Deployment Report including the pre-check results, the actual release path used, and the required health-check outcomes.

Frequently Asked Questions about deploy-ship

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

FAQPage Schema
How do I verify production deploy readiness before releasing?

Production deploy readiness is verified by enforcing deterministic pre-deployment gates that validate CI checks, build artifacts, and change scope via git diff analysis. A release checklist confirms all tests pass before any deployment step is executed.

What is a post-deploy SLO smoke window and how does it work?

A post-deploy SLO smoke window monitors operational health metrics like error rate, latency, throughput stability, and auth success after deployment. If SLO thresholds are exceeded, it triggers rollback recommendations to prevent prolonged production issues.

How do I run a release checklist for a repository with no actual deploy surface?

For repositories with no deploy surface, the release checklist validates only repo-supported release paths and skips invented deploy routes. It still enforces pre-deployment gates, CI verification, and git diff analysis to assess change scope before packaging or publishing.

Can I automate rollback recommendations based on health checks after a production deployment?

Yes, rollback recommendations are generated automatically when post-deploy health checks exceed defined SLO thresholds. The system monitors error rate, latency, and throughput stability during the smoke window to decide whether to continue monitoring or trigger a rollback.

What's the best way to enforce hard quality gates during a production deployment?

Hard quality gates are enforced by applying a repeatable deployment checklist that validates CI results, build readiness, and change size via git diff and log review. Deployment execution only proceeds through repo-supported paths, avoiding risky or incomplete releases.

When should I not use an automated deployment checklist for production releases?

An automated deployment checklist may not suit workflows where the repository exposes no supported release path or where custom deployment routes are required. It validates only repo-supported paths and will not invent deploy surfaces that the repository does not explicitly provide.