Run any Skill in Manus with one click

shipyard-review

Stars65

Forks3

UpdatedJune 19, 2026 at 21:05

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

lgbarn

lgbarn/shipyard

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

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.

More from this repository

same repository

import-spec

lgbarn/shipyard

Import a spec-kit feature spec into Shipyard, replacing brainstorming. Use when a spec-kit feature directory exists with spec.md.

2026-06-1965

shipyard-state

lgbarn/shipyard

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.

2026-06-1965

shipyard-codex-orchestration

lgbarn/shipyard

Use when running any multi-step Shipyard workflow under Codex — build, audit, plan, ship, review, research, or map. Explains how Shipyard's parallel-agent workflows degrade to inline sequential execution in Codex, and routes intent to the right workflow skill. Trigger when the user says "build the plan", "audit this", "ship it", "review the code", "run the shipyard build", or asks how Shipyard works in Codex.

2026-06-1965

shipyard-map

lgbarn/shipyard

Use when performing brownfield analysis on an existing codebase under Codex — onboarding to a new project, generating codebase documentation, or understanding legacy code. Trigger when the user says "map this codebase", "help me understand this code", "document this project", "I just inherited this repo", or runs shipyard init on existing code. This is the Codex inline-sequential form of the mapper agent.

2026-06-1965

shipyard-research

lgbarn/shipyard

Use when conducting domain research, evaluating technology options, investigating ecosystem choices, or gathering knowledge for a development phase under Codex. Trigger when the user says "research X", "what are our options for", "evaluate these libraries", "what's the best approach to", or before planning a phase. This is the Codex inline-sequential form of the researcher agent.

2026-06-1965

shipyard-ship

lgbarn/shipyard

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.

2026-06-1965

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)

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.