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 to inspect or manage Shipyard project state under Codex — show status, resume a previous session, cancel/pause in-progress work, or roll back to a checkpoint. Trigger when the user says "shipyard status", "what's the status", "resume", "continue where we left off", "cancel",
$ npx -y skills add lgbarn/shipyard --skill shipyard-state --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/shipyard-stateContext preview
The summary Claude sees to decide when to auto-load this skill.
Use to inspect or manage Shipyard project state under Codex — show status, resume a previous session, cancel/pause in-progress work, or roll back to a checkpoint. Trigger when the user says "shipyard status", "what's the status", "resume", "continue where we left off", "cancel",
name: shipyard-state description: Use to inspect or manage Shipyard project state under Codex — show status, resume a previous session, cancel/pause in-progress work, or roll back to a checkpoint. Trigger when the user says "shipyard status", "what's the status", "resume", "continue where we left off", "cancel", "pause this", "roll back", or "restore the checkpoint". Codex has no SessionStart hook, so this skill loads state on demand.
In Claude Code, Shipyard's `SessionStart` hook auto-injects project state at the start of every session. **Codex has no such hook**, so state is not loaded automatically — you must read it on demand with the bundled scripts before acting. All state lives under `.shipyard/` (STATE.json, HISTORY.md, ROADMAP.md, PROJECT.md, config.json).
Always run the read step first; if `.shipyard/STATE.json` is absent, tell the user there is no Shipyard project here (suggest `shipyard init`) instead of inventing state.
bash scripts/state-read.sh # prints JSON context (current phase, position, status)
Then also read `.shipyard/HISTORY.md` and `ROADMAP.md` for the fuller picture, and present a clear dashboard: current phase, position, status, and recent history.
bash scripts/state-read.sh
Read STATE.json for the current phase/position/status and HISTORY.md for what happened, then continue the workflow from there. If no state exists, there is nothing to resume.
Checkpoint first, then mark the work paused so it can be resumed later:
bash scripts/checkpoint.sh "pre-cancel-$(date +%s)" # git tag rollback point bash scripts/state-write.sh --phase <N> --position "<where you stopped>" --status paused
Only cancel work that is actually in progress (`building`/`in_progress`/`planning`). If it is already paused or complete, say so rather than writing redundant state.
Checkpoints are git tags created by `checkpoint.sh`. List them and revert with git:
git tag -l 'shipyard-*' # or however the project tags checkpoints git checkout <checkpoint-tag> # inspect, or reset per the user's intent
This is a destructive git operation — confirm with the user before resetting, and never force-reset their working tree without explicit instruction.
Everything here works identically to Claude Code except that state is pulled on demand instead of auto-injected. The teammate lifecycle hooks (idle/task-completed/stop) do not exist in Codex — that is expected, not a regression, because Codex runs single-context.
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…