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…
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.
/shipyard-shipContext 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
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.
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.
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.
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
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…
Use when shipping features with public interfaces that lack docs, generating documentation, updating README files, writing API docs, creating architecture…
Use when starting feature work that needs a branch, creating worktrees for isolation, making atomic commits during development, or completing a development…
Import a handwritten spec document into Shipyard, replacing brainstorming. Use when a freeform spec, requirements, or design document exists.
Import a spec-kit feature spec into Shipyard, replacing brainstorming. Use when a spec-kit feature directory exists with spec.md.
Use when working with Terraform (.tf, .tfvars), Ansible (playbooks, roles, inventory), Docker (Dockerfile, docker-compose.yml), Kubernetes (manifests, Helm…