/shipyard-ship
Use when delivering or releasing a completed Shipyard phase under Codex — final verification, pre-ship security audit, documentation, and release. Trigger when the user says "ship it", "ship this phase", "release this", "we're done — finalize", or "run the shipyard ship
$ npx -y skills add lgbarn/shipyard --skill shipyard-ship --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/shipyard-ship
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when delivering or releasing a completed Shipyard phase under Codex — final verification, pre-ship security audit, documentation, and release. Trigger when the user says "ship it", "ship this phase", "release this", "we're done — finalize", or "run the shipyard ship
SKILL.md
shipyard-ship.SKILL.mdname: shipyard-ship
description: Use when delivering or releasing a completed Shipyard phase under Codex — final verification, pre-ship security audit, documentation, and release. Trigger when the user says "ship it", "ship this phase", "release this", "we're done — finalize", or "run the shipyard ship workflow". This is the Codex inline-sequential form of the /shipyard:ship orchestration.
Shipping a phase (Codex inline-sequential)
This is Shipyard's `/shipyard:ship` delivery flow, adapted for Codex. The flow is already sequential (verify → audit → document → deliver), so it maps cleanly to a single context — you adopt each role in turn rather than dispatching subagents.
**Degradation note:** the audit and documentation steps run as inline personas, not fresh-context subagents. Be deliberately thorough on the audit step — shipping is the final gate, so do not let earlier context make you assume the code is fine.
Run `scripts/state-read.sh` first if state isn't loaded.
Steps (run each in order; stop on a hard failure)
1. **Pre-ship verification.** Use the `shipyard-verification` skill to confirm success criteria are met and the phase is actually complete. 2. **Run the test suite.** All tests must pass. A failure here blocks the ship. 3. **Pre-ship security audit.** Adopt the auditor mandate (OWASP Top 10, secrets, dependency vulnerabilities). Shipping is the final security gate — this runs even if the build skipped auditing. If a passing audit already exists and nothing changed since, verify it has no unresolved critical findings instead of re-auditing. **Any unresolved critical finding blocks the ship.** 4. **Documentation.** Adopt the documenter mandate — generate/refresh API, architecture, and user-facing docs in `docs/`. If up-to-date docs already exist from the build, verify completeness instead of regenerating. 5. **Capture lessons.** Use the `lessons-learned` skill to record what was learned this phase. 6. **Deliver.** Finalize per the project's release convention (version bump, CHANGELOG, tag, PR/merge). Never auto-merge without the user's go-ahead unless they've authorized it.
Done means
Verification passed, tests green, no unresolved critical audit findings, docs complete, lessons captured, and the release artifact prepared. Report the status of each gate explicitly — do not claim "shipped" if any gate was skipped.
Read more
name: shipyard-ship description: Use when delivering or releasing a completed Shipyard phase under Codex — final verification, pre-ship security audit, documentation, and release. Trigger when the user says "ship it", "ship this phase", "release this", "we're done — finalize", or "run the shipyard ship workflow". This is the Codex inline-sequential form of the /shipyard:ship orchestration.
Shipping a phase (Codex inline-sequential)
This is Shipyard's `/shipyard:ship` delivery flow, adapted for Codex. The flow is already sequential (verify → audit → document → deliver), so it maps cleanly to a single context — you adopt each role in turn rather than dispatching subagents.
**Degradation note:** the audit and documentation steps run as inline personas, not fresh-context subagents. Be deliberately thorough on the audit step — shipping is the final gate, so do not let earlier context make you assume the code is fine.
Run `scripts/state-read.sh` first if state isn't loaded.
Steps (run each in order; stop on a hard failure)
1. **Pre-ship verification.** Use the `shipyard-verification` skill to confirm success criteria are met and the phase is actually complete. 2. **Run the test suite.** All tests must pass. A failure here blocks the ship. 3. **Pre-ship security audit.** Adopt the auditor mandate (OWASP Top 10, secrets, dependency vulnerabilities). Shipping is the final security gate — this runs even if the build skipped auditing. If a passing audit already exists and nothing changed since, verify it has no unresolved critical findings instead of re-auditing. **Any unresolved critical finding blocks the ship.** 4. **Documentation.** Adopt the documenter mandate — generate/refresh API, architecture, and user-facing docs in `docs/`. If up-to-date docs already exist from the build, verify completeness instead of regenerating. 5. **Capture lessons.** Use the `lessons-learned` skill to record what was learned this phase. 6. **Deliver.** Finalize per the project's release convention (version bump, CHANGELOG, tag, PR/merge). Never auto-merge without the user's go-ahead unless they've authorized it.
Done means
Verification passed, tests green, no unresolved critical audit findings, docs complete, lessons captured, and the release artifact prepared. Report the status of each gate explicitly — do not claim "shipped" if any gate was skipped.
A Claude Code plugin for structured project execution. Plan work in phases, build with parallel agents and TDD, review with security audits and quality gates, and ship with confidence.
Repo: lgbarn/shipyard
Other skills on shipyard.
- /code-simplification
Use after implementing features, before claiming a phase is complete, when reviewing AI-generated code, or when code feels overly complex. Also use when you notice repeated patterns across files, a function exceeds 40 lines, nesting exceeds 3 levels, or an abstraction has only
Open skill - /documentation
Use when shipping features with public interfaces that lack docs, generating documentation, updating README files, writing API docs, creating architecture documentation, or when documentation is incomplete or outdated. Also use when adding breaking changes, implementing complex
Open skill - /git-workflow
Use when starting feature work that needs a branch, creating worktrees for isolation, making atomic commits during development, or completing a development branch via merge, PR, preserve, or discard. Also use when the user says "set up worktree", "create PR", "finish this
Open skill - /import-spec-file
Import a handwritten spec document into Shipyard, replacing brainstorming. Use when a freeform spec, requirements, or design document exists.
Open skill - /import-spec
Import a spec-kit feature spec into Shipyard, replacing brainstorming. Use when a spec-kit feature directory exists with spec.md.
Open skill - /infrastructure-validation
Use when working with Terraform (.tf, .tfvars), Ansible (playbooks, roles, inventory), Docker (Dockerfile, docker-compose.yml), Kubernetes (manifests, Helm charts), CloudFormation, or any infrastructure-as-code files. Also use when running terraform plan/apply, building Docker
Open skill

