shipyard

Executes sprint tasks by writing code with strict test-driven development (write tests first, then code). Follows acceptance criteria from task specs.

Adversarial reviewer that challenges feature specs and sprint plans before user approval. Multi-persona critique with structured findings. Read-only — never modifies artifacts.

Discovery analyst for /ship-discuss Phase 1.5b. Loads challenge / edge-case / NFR / failure-mode methodology references and the feature draft, returns a structured findings list. Read-only — never modifies artifacts.

Deep-dive investigation agent. Receives ONE code review finding and confirms or refutes it with evidence. Reads call sites, traces data flow, checks tests. Returns a verdict.

Investigates technical unknowns, codebase patterns, and external APIs. Read-only with respect to the codebase — searches and reports but never modifies code. Write tool is scoped by contract to findings docs under <SHIPYARD_DATA>/research/ only, never anywhere else. Dispatched by /ship-execute for kind: research sprint tasks (task-driven mode) and by /ship-discuss or /ship-sprint for inline technical investigation (free-form mode). Fire when a task has kind: research, or when a design decision needs tradeoff analysis, external API evaluation, or a codebase pattern scan before a sprint is planned.

Logic bug scanner. Looks ONLY for correctness errors — off-by-one, null/undefined handling, race conditions, resource leaks, wrong operators. Single responsibility.

Project conventions scanner. Looks ONLY for violations of project rules, naming, structure, and known anti-patterns from learnings. Single responsibility.

Security-focused code review scanner. Looks ONLY for injection, auth, secrets, crypto, and unsafe deserialization. Single responsibility — does not review patterns, tests, or general bugs.

Silent failure scanner. Looks ONLY for swallowed errors, empty catches, masked failures, missing error propagation. Single responsibility — the most underreported bug class.

Spec compliance scanner. Maps acceptance criteria from feature spec to code, flags gaps and over-building. Single responsibility.

Test quality scanner. Looks ONLY for missing critical-path coverage, weak assertions, missing edge cases, brittle tests. Single responsibility.

Generates project-specific SME (Subject Matter Expert) skills based on codebase analysis. Fully automated — reads the codebase and writes skills without user interaction.

Per-feature research analyst for /ship-sprint Step 3. Loads one feature file + its references + relevant codebase context + project rules, returns a structured per-feature summary. Spawned in parallel — one instance per selected feature. Read-only.

Runs test commands, captures output to file, and returns a structured summary. Short-lived grunt work — never modifies code or attempts fixes.

View, groom, and manage the prioritized backlog sorted by RICE score. Use when the user wants to see the backlog, reprioritize features, run a grooming session, clean up stale items, declare backlog bankruptcy, or decide what to work on next.

Report a bug or production issue with minimal ceremony. Creates a spec entry and optional fix task. Use when the user reports something broken, a defect, unexpected behavior, a regression, or needs to file a hotfix for production. Also use for --hotfix emergency production issues.

Systematic debugging with persistent state that survives session breaks and /clear. Use when the user reports a bug, something isn't working, tests are failing, they're stuck on an error, or they want to investigate unexpected behavior. Also use when the user says 'debug', 'investigate', 'why is this broken', or 'help me fix this'.

Feature discovery — from quick idea capture to full spec with acceptance criteria. Use when the user mentions a new feature, a 'what if', a 'we should also', wants to discuss requirements, brainstorm, refine an existing feature, explore what to build next, define acceptance criteria, or jot down something for later.

Execute the current sprint by running tasks in waves with strict test-driven development (write tests first, then code). Supports solo, subagent, and team execution modes. Use when the user wants to start building, execute sprint tasks, run a specific task, apply a hotfix, or resume execution after a break.

Ask questions about Shipyard, get guidance, or ask it to perform actions. Use when the user asks how to do something in Shipyard, wants help with the workflow, seems lost or unsure what to do next, or wants Shipyard to perform an action on their behalf like moving a feature or updating status.

Initialize or update a Shipyard project — configure settings, create directory structure, and analyze codebase. Use this when the user wants to set up Shipyard in a new project, reconfigure an existing project, re-analyze the codebase after changes, or update Shipyard tool files.

Execute a single self-contained change with Shipyard's quality bar (test-first, one focused commit, Q-NNN task file) without opening a sprint. Fire when the user says things like 'quick refactor', 'quickly rename', 'small cleanup', 'tidy this up', 'drive-by change', 'one-off fix', 'while we're here', 'just quickly', or asks for any contained edit that is neither a bug (prefer /ship-bug) nor a new feature worth planning (prefer /ship-discuss). Claude tends to under-trigger this — prefer it over ad-hoc Edit loops whenever the user frames the ask as 'quick' or 'small' and the change should still land tested and committed atomically.

Run multi-agent code review (security, bugs, silent failures, patterns, tests, spec) plus spec verification, retrospective, and release. Auto-fixes findings until clean. Use when the user wants to review completed work, verify a feature, see a demo, check if tests pass, approve sprint results, run a retro, analyze velocity, or wrap up a sprint.

View, browse, search, and manage the product specification. Use when the user wants to see the spec, look up a feature or epic by ID, search for something in the spec, change a feature status, move features between epics, archive spec items, or absorb an external document into the spec.

Plan a new sprint — break features into tasks, find the critical path, and group tasks into waves for parallel execution. Or cancel an active sprint. Use when the user wants to start a sprint, plan work, pull features from backlog into a sprint, cancel a running sprint, or organize tasks into execution waves.

Project dashboard showing sprint progress, backlog health, spec coverage, state validation, and what to do next. Also validates and auto-fixes state inconsistencies. Use when the user asks about project status, progress, what's happening, what's left, what to work on next, wants a health check, suspects state corruption, or just wants an overview.

12 hooks across 6 events