ship-check

Systematic bug hunt focused on patterns that survive code review and test audit — description-vs-implementation mismatches, SQL correctness, type coercion bugs, boundary/off-by-one errors, behavioral asymmetry, and input validation gaps. Derived from analysis of 40+ bugs found by Qodo and CodeRabbit that the ship-check pipeline (pr-review, code-quality, test-audit) missed. Use when asked to "bug check", "check for bugs", "deep correctness check", "look for subtle bugs", or as part of the ship-check pipeline. NOT for: code style (use code-quality), test design (use test-audit), security review (use security-review), or high-level correctness review (use pr-review).

Readability and convention compliance pass on production code, grounded in the project's AGENTS.md and the user's vault memory preferences. Use when asked to "do a readability pass", "code quality pass", "make more readable", "review code quality", "clean up against conventions", "simplify with my preferences", or "review against AGENTS.md". Different from the built-in /simplify (which is generic) — this loads project-specific conventions and personal preferences. NOT for: test file audits (use test-audit), full PR review (use pr-review), or generic simplification without convention grounding (use /simplify).

Read code as someone who has never seen the codebase — no conventions, no history, no attachment — and report every place a newcomer pauses: a name that had to be traced, a loop or branch with no stated reason, a term never introduced, a comparison that had to be reasoned about, a comment that promised something the code did not do. Report only; never edits. The dispatcher may name who the reader is (a persona — "a junior developer", "a developer coming from Python"); the default is an experienced developer new to the codebase. Use when asked to "read this as a stranger", "fresh eyes on this", "would a newcomer understand this", "would a junior follow this", or to compare two candidate versions of a function on readability. NOT for: convention compliance (use code-quality), correctness or bug hunting (use pr-review / bug-check), or test review (use test-audit).

Monitor PR status — CI checks, review bot findings, unresolved conversations — and address + resolve bot comments. After pushing fixes, waits for and handles new bot review comments before declaring merge-ready. Use when asked to "check PR status", "monitor this PR", "check CI", "resolve PR comments", "address review comments", "mark conversations resolved", or when waiting on a PR to be merge-ready. NOT for: initial code review (use pr-review), post-merge testing (use verify), or reviewing the diff itself.

Project-aware PR review grounded in AGENTS.md conventions and vault memory. Runs a multi-dimension review: correctness, convention compliance, test quality, security, performance, and conditional checks (TDQS scoring, feature surface docs). Use when asked to "review this PR", "review PR #X", "do a thorough review", "review against AGENTS.md", or "review with my preferences in mind". Complements the built-in /code-review (which is generic) by loading project-specific conventions and personal preferences. NOT for: quick CI failure diagnosis (use pr-monitor), post-merge testing (use verify), or code simplification without a PR context (use code-quality).

Run the full post-implementation review pipeline: pr-review -> fresh-eyes -> code-quality -> test-audit -> bug-check -> pr-monitor. Phases 1-5 run as dedicated agent types (ship-check plugin) with skills preloaded — genuine fresh eyes with no inherited context. Phase 6 (pr-monitor) runs inline for user interaction. Use when asked to "ship check", "review pipeline", "full review", "run all reviews", or after implementation is complete and ready for review. NOT for: single-dimension review (use the individual skill), quick CI check (use pr-monitor), or post-merge testing (use verify).

Audit test files against the project's AGENTS.md test conventions, ensuring tests meet the bar for high-quality behavioral specs. Also checks whether production code changes have adequate test coverage (coverage gap analysis). Use when asked to "audit tests", "check test quality", "review tests against AGENTS.md", "do a test pass", "check test conventions", "ensure tests are high quality", or "are there missing tests". Focuses on test design, assertion quality, and coverage gaps — not code coverage metrics. NOT for: production code quality (use code-quality) or full PR review (use pr-review).

Review MCP tool definitions as the client receives them: read the tool list a server sends (name, description, input schema), mark each changed tool against a quality rubric, and compare it with the list before the change to find text changed in tools nobody meant to touch, facts the change dropped, description prose that repeats the schema, a bullet filed under the wrong lead-in or a phrase with no named referent, and failures the code returns that the description never mentions. Report only; writes no file except its own report. Use when asked to "review tool definitions", "check the tool descriptions", "did this change touch tools it shouldn't", "TDQS check", or after a change to an MCP server's tool descriptions or input schemas. NOT for: general PR review (use pr-review), whether a description's claims match the code beyond its error list (use bug-check), or README and docs prose (use code-quality).