ship

Enforce spec-first development, peer review, and controlled deployment in Git workflows.

8|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/usurobor/cnos --skill ship-usurobor
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ship
Source: https://github.com/usurobor/cnos/tree/main/src/packages/cnos.eng/skills/eng/ship
Command: npx skills add https://github.com/usurobor/cnos --skill ship-usurobor

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Ship governance and release discipline are often manual and error-prone. This Skill enforces spec-first development, peer review, and controlled deployment to production to reduce risk of broken releases.

Core Features & Use Cases

  • Spec-first workflow: write a spec, then tests, then implement code.
  • Prevent self-merge: only reviewers can merge; authors are notified.
  • Bug-fix and feature flows: dedicated sequences for validating changes before shipping.
  • Merge-to-main with proper verification and post-ship cleanup.

Quick Start

Follow the feature flow: write a spec, add failing tests, implement code to satisfy the spec, run tests to verify, and ship by merging to main.

Frequently Asked Questions about ship

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

FAQPage Schema
How do I enforce a spec-first development workflow in Git?

Spec-first development in Git is enforced by writing a spec, adding failing tests, implementing code to satisfy the spec, and verifying tests before shipping. This workflow preempts unsafe releases by ensuring code matches requirements before deployment.

How can I prevent developers from self-merging their own code?

To prevent self-merge in a Git workflow, governance constraints enforce that only reviewers can merge code, not the author. Authors are automatically notified that they cannot merge their own changes, ensuring peer review is required before deployment.

What is the best way to validate bug fixes before deploying to production?

The best way to validate bug fixes before production deployment is using a dedicated bug-fix flow that enforces spec-first development, peer review, and controlled deployment. This includes writing specs, adding tests, implementing code, and verifying changes before merging to main.

How do I implement controlled deployment gates for feature releases?

Controlled deployment gates for feature releases are implemented by enforcing spec-first development and peer review before merging to main. The feature flow requires writing specs, adding failing tests, implementing code, running tests to verify, and shipping only after verification passes.

Does this release governance workflow require any specific testing frameworks?

No specific testing frameworks are required as dependencies. The workflow applies to feature development and bug fixes within a Git-driven workflow, enforcing that tests are written and verified before shipping, but it does not mandate particular testing tools.

What is included in the post-ship cleanup process after merging to main?

Post-ship cleanup after merging to main is part of the controlled deployment workflow that follows proper verification. The process ensures release discipline by completing the feature or bug-fix flow with cleanup actions after the reviewer has successfully merged the verified code.