inno-ship

Pushes code, waits for safety gates, and cuts the release tag that deploys an Innovation Platform app.

Updated Jul 18, 2026
One-click install
npx skills add https://github.com/dlaporte/claude-plugins --skill inno-ship-dlaporte
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: inno-ship
Source: https://github.com/dlaporte/claude-plugins/tree/main/plugins/innovation-platform/skills/inno-ship
Command: npx skills add https://github.com/dlaporte/claude-plugins --skill inno-ship-dlaporte

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Releasing an app on the davidlaporte.org Innovation Platform requires pushing to the default branch, waiting for eight safety gate jobs to pass, and then cutting a v* release tag — the only action that actually triggers a deploy. This Skill orchestrates that entire release flow so shipping is one conversation, even for non-technical users. ## Core Features & Use Cases - Pre-flight validation: Verifies the plugin version against the platform, confirms the app is actually built (no .needs-build marker), checks the npm lockfile, and validates declared app variables before tagging. - Gate-driven release: Commits, pushes, watches the CI gate jobs (config-integrity, secrets, sast, deps, container, and more), then creates the semver tag and GitHub Release that triggers the deploy. - Failure triage: Maps every failing gate job to its likely cause and fix, with plain-language reporting and a support-bundle escalation path after two failed fix attempts. - Use Case: A user finishes building their app and says "ship it" — the Skill runs the checks, pushes, waits for green gates, tags v1.0.0, and reports the live Okta-gated URL. ## Quick Start Ship my app to the Innovation Platform and tell me the live URL when the release deploy finishes.

Frequently Asked Questions about inno-ship

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

FAQPage Schema
How do I deploy an app on the Innovation Platform?

Push your commits to the repository's default branch so the safety gate jobs run, then create and push a v* release tag — tagging is what actually triggers the deploy job. This Skill automates the whole sequence and reports the live URL when the release run succeeds.

Why didn't my push deploy my app?

Pushes to the default branch only run the safety gates; they never deploy. Deploys are release-driven, so you must tag a v* release and push the tag. The deploy broker issues deploy tokens for tag refs only and rejects pushes with 403 deploy_denied.

What happens if a safety gate fails before release?

The Skill reads the failing job's logs, maps it to a known cause (for example a gitleaks finding, a Trivy CVE, or a missing package-lock.json), fixes the root cause, and re-pushes. It never tags on top of red checks, and after two failed fix attempts it offers to create a support bundle.

Can I verify the deploy by curling the app's URL?

No — the Skill explicitly forbids resolving the hostname after a first deploy. Fresh DNS records take up to a minute to propagate, and a premature lookup can cache a negative result on the user's machine. The deploy job status and the app_status MCP tool are the authoritative signals.

What are the prerequisites before shipping an app?

The inno-safety-preflight must have passed in the session, the app must actually be built (no app/.needs-build marker), function-shaped apps need a committed app/package-lock.json, and the plugin version must pass the platform's version gate via get_platform_status.