ship

Name: ship
Author: raphaelsalaja

github.com/raphaelsalajaCloud & DevOps6294 installsUpdated 4d ago

About ship

ship is a skill for taking finished changes from a working tree through commit, push, and deployment checks. It guides developers through small Conventional Commits, pull requests, CI monitoring, and confirming the live result.

Key features

01Checks changed files and scans for secrets
02Creates a commit per logical change
03Uses Conventional Commit messages
04Pushes and manages merges and branches
05Monitors CI checks
06Verifies the live deployment

Use cases

01Shipping a finished feature or fix
02Preparing separate pull requests for changes
03Confirming CI and production status

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/raphaelsalaja/skills --skill ship

After installing, type/shipin Claude Code to confirm it loaded.

Bundled filesagents/openai.yaml

Details

From the project README

Ship

This skill takes finished work from the working tree to production. It commits in small pieces, pushes, merges, watches checks and confirms the result is live.

Push means push

When the user says push, ship or merge, do every step to the end. Handing a command back to the user is a finding unless it needs their credentials or their approval. A secret in a commit is always HIGH.

Checking the change itself runs in verify before this skill starts.

1. Check the tree

Run git status and read every changed file. Name any file you did not change in this task and ask before committing it. Committing a stray file is ship-flag-stray-files. Scan the diff for keys, tokens, passwords and .env files. A committed secret is ship-no-secrets.

2. Commit per change

Make one commit per logical change. One commit for a feature, a fix and a rename is ship-commit-per-change. Write every message as a Conventional Commit: type(scope): summary in the imperative, lowercase and with no full stop. Use feat, fix, docs, refactor, chore or another standard type, and mark a breaking change with ! after the type. A message like "Remove the archive." is ship-conventional-commits. In a package that publishes releases, add the changeset with the change. A release-bound change with no changeset is ship-changeset-for-packages.

3. Push, merge and tidy

Push the branch. When asked to merge, merge it, delete the branch and switch back to the default branch. A merged branch left behind is ship-merge-and-tidy. Open one pull request per bug or feature. A pull request bundling three fixes is ship-one-pr-per-bug. A pull request that changes UI carries a screenshot. That is ship-screenshot-ui-prs.

4. Watch the checks

Wait for CI and fix what fails. Reporting "pushed" while checks are red or still running is ship-watch-checks.

5. Close the loop

When the change fixes an issue, link it, close it and reply where it was raised. A fixed bug with its issue left open is ship-close-the-loop. When the change deploys, open the live URL or the published version and check it. "Deployed" with no look at production is ship-confirm-live.

6. Hand back only what needs the user

Do every step you can run yourself. Ask only for a login, a two-factor code or an approval. Say exactly which. A list of commands for the user to run is ship-do-the-steps.

The pair

Every check is a pair. The broken line sits beside the line that replaces it.

Rule	Broken	Replacement
`ship-flag-stray-files`	`git add -A` with someone else's file in the tree	The file named, then a question
`ship-no-secrets`	`.env.local` committed	`.env.local` ignored, the secret flagged for rotation
`ship-commit-per-change`	One commit for a feature, a fix and a rename	Three commits, one per change
`ship-conventional-commits`	`Remove the archive.`	`chore: remove the archive`
`ship-changeset-for-packages`	A package fix with no changeset	The changeset in the same commit
`ship-merge-and-tidy`	Merged, the branch still checked out	Merged, deleted, back on `main`
`ship-one-pr-per-bug`	One pull request for three bugs	Three pull requests
`ship-screenshot-ui-prs`	A UI pull request with no image	A screenshot in the description
`ship-watch-checks`	"Pushed" while CI runs	"Pushed, all checks pass"
`ship-close-the-loop`	The fix merged, the issue open	The issue linked, closed and answered
`ship-confirm-live`	"Deployed"	"Live at the production URL, checked"
`ship-do-the-steps`	"Run `npm publish` when ready"	Published, or "needs your two-factor code"

Reporting

Severity. HIGH is a committed secret, a stray file committed or a release with failing checks. MEDIUM is a bundled commit or pull request, an open issue after the fix or steps handed back that could have run. LOW is a message that is not a Conventional Commit, a missing screenshot or a branch left after merge.

Format. One finding per root cause, citing the step when no file applies:

file:line - [rule-id] what is wrong
step 3 - [rule-id] what is wrong

Then a Rule | Count | Severity summary. Block when any HIGH remains, Approve otherwise. Mark every check you could not watch to the end as Not verified.

Comments

Markdown supported

Details

Author: raphaelsalaja
Repository: raphaelsalaja/skills
Category: Cloud & DevOps
Installs: 94
GitHub stars: 62

Report

More skills

All skills

lark-apps

open.feishu.cn

778.5k

Develop and host Miaoda (Spark/Miaoda) apps: app creation, local full-stack development, cloud generation and iteration, creative design (UI mockups / interactive prototypes / wireframes / landing pages / dashboards / slide decks / visual exploration), integration of AI-related capabilities, Feishu platform capabilities, or other external capabilities; log/Trace/monitoring metric/PV/UV queries; environment variable management; app collaborators and collaboration permissions; app roles and members; and automation triggers (scheduled / record changes / Webhook / Feishu approvals). Use when users want to develop or create a system, tool, platform, or app; develop locally or in the cloud, modify, deploy, publish, launch, or get a shareable link; create a page or website with HTML and deploy it to Miaoda; design, create a mockup, prototype, wireframe, PPT, deck, or visual exploration; or mention Miaoda/Spark/Miaoda apps (links like `/app/app_xxx` or `/page/<token>`, runtime domains like *.aiforce.cloud), app databases, app file storage, open API Keys, visibility, app collaborators/developer permissions, app roles/role members, production logs, API request volume, error volume, latency, traffic, environment variables, or setting up automation tasks, scheduled triggers, or approval-triggered automation for Miaoda apps. Not for regular cloud drive file uploads (lark-drive), Feishu document editing (lark-doc), or native slide creation (lark-slides).

azure-prepare

github.com/microsoft

647.1k

Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.

azure-ai

github.com/microsoft

646.3k

Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.

azure-deploy

github.com/microsoft

646.0k

Execute Azure deployments for already-prepared applications that have an existing .azure/deployment-plan.md and infrastructure files. Do not use this skill when the user asks to create a new application; use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform"; use azure-prepare for these.