Qcheckt
Review test code for coverage and quality — are the right behaviors tested, edge cases included, assertions meaningful, and tests free of tautologies/flakiness. Use when reviewing or writing tests for a change; qship runs it as a dedicated reviewer in the Phase-2 review fan-out.
Qmemory
Capture a durable lesson from this work into persistent memory — a non-obvious gotcha, a confirmed convention, or feedback worth re-applying on future tasks. Use when you learn something that should outlive the session; qship runs it as Step 11.7 to record review/bug lessons.
Qmanualt
Perform comprehensive {{COMPANY_SLUG_UPPER}} acceptance testing with live UI, API, DB, and evidence capture for every acceptance criterion.
Configure
One-time interactive configurator for the qship skill catalog. Run this immediately after installing the qship plugin (the SessionStart hook will remind you on first use). Walks through a short questionnaire (7 rounds, ~two dozen questions) plus a per-repo loop (1 repo or 100, the configurator doesn't care), renders the full skill set into your ~/.claude/skills/ tree, then verifies the install an…
Qcheck
Review code changes for correctness, security, and convention adherence — the general-purpose code reviewer. Use on a diff or recent changes before committing or opening a PR to catch bugs, risky patterns, and style violations; the central review step in the qship pipeline.
Qlocalclonedb
Clone a staging tenant's database into a named local Postgres DB for realistic local testing — copies schema + data so you can reproduce issues against production-shaped data. Use before local E2E when you need real tenant data; qspinuplocal calls it when a project ships a local-DB bootstrap.
Qclean
Review a change for defensive/dead code that should be removed — unnecessary null-guards, speculative branches, leftover scaffolding, over-engineering. Use after implementing a feature to strip code that adds noise without adding value; qship runs it as Step 7.4.
Qbcheck
Validate candidate bugs before reporting them — an adversarial second pass that confirms each finding is real (reproducible, correctly root-caused) and filters out false positives. Use after a bug hunt or code review to gate which findings are worth surfacing; qship runs it as the Step 10 quality gate before any bug is acted on.
Qshipmaster
Epic-level orchestrator for qship. Takes a Jira Epic ID, builds a topologically-sorted wave plan from its children, spawns one qship-persist.sh per ticket per wave in parallel, merges each wave into a consolidated epic branch, runs a lightweight wave-gate after each wave (migration check + targeted tests + 2 bug hunters + qbcheck, blocks only on Critical) and ONE full epic-level Phase 2 review af…
Qbug
Hunt for the root cause of a bug — trace symptoms back to the underlying defect and report findings, without applying fixes (hunt-only, so you stay in control of the change). Use when investigating a failure, unexpected behavior, or a flaky test and you want the true cause rather than a surface patch.
Qshipphasecheck
Hard gate between qship pipeline phases. Validates that ALL steps in the current phase completed before allowing the next phase to start. Run between Phase 2→3 and Phase 3→4 transitions. Blocks progression if ANY step was skipped — especially qbcheck (Step 10).
Qmigrationdevcheck
Validate an Alembic migration chain before it ships — checks for multiple heads, broken/cyclic down-revisions, divergent branches, and migrations that won't apply cleanly on top of the base branch. Use when a change adds or edits files under `alembic/versions/`; qship runs it automatically when the diff touches migrations.
Qshipcheck
Validates that all orchestrator Phase 2 (review), Phase 3 (acceptance), and Phase 4 (deliver) steps were executed after qship pipeline completion. Run this after qship finishes to catch any skipped steps.
Qcheckf
Review a single function in depth — signature, parameters, edge cases, error handling, and whether it does one thing well. Use when you want a focused critique of one function (not a whole diff), e.g. a complex or hot-path routine you're about to ship.
Qplan
Review an implementation plan before any code is written — checks it against the actual codebase for missing steps, wrong assumptions, ignored existing patterns, and unhandled edge cases. Use after drafting a plan/TRD and before implementing; qship runs it as Step 6.
Qcomponent
Review a frontend UI component — props/state design, accessibility, render performance, reuse of existing components, and adherence to the project's UI conventions. Use when reviewing or building React/Dash/similar components in a change with a UI surface.
Qe2etest
Run quick end-to-end smoke testing for {{COMPANY_SLUG_UPPER}} changes by tracing changed code paths through the real local stack and verifying behavior live.
Qship
Full Jira-ticket → PR pipeline (plan, implement, review, test, ship). Supports parallel and epic-mode execution. Two independent engine knobs — `provider=claude|codex` chooses the Step 7 implementer (default Claude Opus 4.7 1M, medium reasoning), and `reviewer=claude|codex` chooses the Phase 2 reviewer (default Claude). Most useful combination beyond defaults is `provider=claude reviewer=codex` (…
Qreuse
Review a change for reuse opportunities — did it reinvent something that already exists in the codebase, and is new code factored so it can be reused. Use after implementing to catch duplicated logic and surface existing helpers/utilities you should call instead; part of qship's simplify/review pass.
Qdirectory
Review where new files/modules were placed — do they sit in the right directory, follow the repo's layering and naming conventions, and avoid creating parallel structures. Use after adding files to confirm the change fits the existing architecture; qship runs it as Step 7.3.
Qspinuplocal
Spin up your primary service locally against a local Postgres DB for testing — env wiring, optional migrations, health check. Single-service by design; adapt the start command to your stack.
Qauthtrailingslash
Audit API routes for the trailing-slash / 307-redirect auth bug — where a missing or extra trailing slash makes the server issue an HTTP 307 redirect and the client silently drops the Authorization header, causing intermittent 401s. Use when reviewing or debugging FastAPI/Starlette (or similar) routes, auth-token loss across redirects, or flaky authenticated endpoints.