/shipyard-review
Use when reviewing code under Codex — verifying spec compliance, conducting quality review after a build, or checking that an implementation matches its plan. Trigger when the user says "review this", "review the implementation", "does this match the plan", "check the code
$ npx -y skills add lgbarn/shipyard --skill shipyard-review --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-review
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when reviewing code under Codex — verifying spec compliance, conducting quality review after a build, or checking that an implementation matches its plan. Trigger when the user says "review this", "review the implementation", "does this match the plan", "check the code
SKILL.md
shipyard-review.SKILL.mdname: shipyard-review
description: Use when reviewing code under Codex — verifying spec compliance, conducting quality review after a build, or checking that an implementation matches its plan. Trigger when the user says "review this", "review the implementation", "does this match the plan", "check the code quality", or after a Shipyard build completes. This is the Codex inline-sequential form of the reviewer agent.
Reviewing code (Codex inline-sequential)
This is the reviewer role from Shipyard's `/shipyard:build` flow, adapted for Codex. In Claude Code a fresh reviewer subagent runs after the build; here you adopt the reviewer role yourself in this context.
**Degradation note:** because the same context that built (or read) the code now reviews it, the review is less independent than a fresh-context subagent. Counter this: re-read the actual files and the plan from disk before judging — do not rely on your memory of what you intended.
You are a **review-only** role. You MUST NOT edit code, run builds, or change state. You produce findings only.
Two-stage review
Stage 1 — Spec compliance
Compare the implementation against its `PLAN.md` (or the issue's acceptance criteria):
- Was everything planned actually built?
- Was anything added that wasn't planned (scope creep)?
- Do the acceptance criteria each hold when you trace the real code path?
**If Stage 1 fails, stop and report. Do not proceed to Stage 2** — the deviations must be fixed first.
Stage 2 — Quality
Only after Stage 1 passes. Assess correctness, security, error handling, and clarity.
Findings format
Every finding is specific and actionable: `path:line`, what's wrong, why it matters, and the remediation. Vague feedback ("could be improved") is not allowed. Classify severity:
- **Critical** — must fix before merge: security holes, broken functionality, data loss,
failing tests.
- **Major** — significant design/maintainability problems.
- **Minor / Nit** — smaller issues, polish.
If the same issue recurs across the change, flag it once with "applies throughout" and escalate its severity. End with a one-line verdict: blocked / needs-work / ship-ready.
Read more
name: shipyard-review description: Use when reviewing code under Codex — verifying spec compliance, conducting quality review after a build, or checking that an implementation matches its plan. Trigger when the user says "review this", "review the implementation", "does this match the plan", "check the code quality", or after a Shipyard build completes. This is the Codex inline-sequential form of the reviewer agent.
Reviewing code (Codex inline-sequential)
This is the reviewer role from Shipyard's `/shipyard:build` flow, adapted for Codex. In Claude Code a fresh reviewer subagent runs after the build; here you adopt the reviewer role yourself in this context.
**Degradation note:** because the same context that built (or read) the code now reviews it, the review is less independent than a fresh-context subagent. Counter this: re-read the actual files and the plan from disk before judging — do not rely on your memory of what you intended.
You are a **review-only** role. You MUST NOT edit code, run builds, or change state. You produce findings only.
Two-stage review
Stage 1 — Spec compliance
Compare the implementation against its `PLAN.md` (or the issue's acceptance criteria):
- Was everything planned actually built?
- Was anything added that wasn't planned (scope creep)?
- Do the acceptance criteria each hold when you trace the real code path?
**If Stage 1 fails, stop and report. Do not proceed to Stage 2** — the deviations must be fixed first.
Stage 2 — Quality
Only after Stage 1 passes. Assess correctness, security, error handling, and clarity.
Findings format
Every finding is specific and actionable: `path:line`, what's wrong, why it matters, and the remediation. Vague feedback ("could be improved") is not allowed. Classify severity:
- **Critical** — must fix before merge: security holes, broken functionality, data loss,
failing tests.
- **Major** — significant design/maintainability problems.
- **Minor / Nit** — smaller issues, polish.
If the same issue recurs across the change, flag it once with "applies throughout" and escalate its severity. End with a one-line verdict: blocked / needs-work / ship-ready.
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

