qship

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.

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` (Opus implements, gpt-5.5 high reasoning hunts bugs) — different model families catch different defects.

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 after the last wave on the cumulative diff, and ships ONE consolidated PR per repo. Two engine knobs — `provider=claude|codex` chooses the Step 7 implementer (default Opus 4.7 1M, medium), and `reviewer=claude|codex` chooses the Phase 2 reviewer (default Claude). The diversified combo `provider=claude reviewer=codex` runs Opus implementing + gpt-5.5 high reviewing for different-family second opinion. Set `QSHIP_PER_WAVE_REVIEW=full` to restore full Phase 2 per wave, or `=none` to skip per-wave review entirely. Resumable, state-driven, idempotent.

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 and required external plugins. Idempotent — re-runnable any time you want to change a value (added a service, new Jira project key, opted into a previously-skipped integration).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Perform comprehensive {{COMPANY_SLUG_UPPER}} acceptance testing with live UI, API, DB, and evidence capture for every acceptance criterion.

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.

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.

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.

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.

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.

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).

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.