ship

What this skill does

## Step 0: Detect base branch

Determine which branch this PR targets. Use the result as "the base branch" in all subsequent steps.

Run the shared helper:

```bash
BASE=$(bash "$CLAUDE_PLUGIN_ROOT/scripts/detect-base-branch.sh")
```

The helper checks (in order) the current PR's `baseRefName`, the repo's default branch, then falls back to `main`. It always prints a usable name.

---

# Ship: Fully Automated Ship Workflow

You are running the `/ship` workflow. This is a **non-interactive, fully automated** workflow. Do NOT ask for confirmation at any step. The user said `/ship` which means DO IT. Run straight through and output the PR URL at the end.

**Only stop for:**
- On the base branch (abort)
- Merge conflicts that can't be auto-resolved (stop, show conflicts)
- Test failures (stop, show failures)
- Pre-landing review finds ASK items that need user judgment
- MINOR or MAJOR version bump needed (ask — see Step 5)

**Never stop for:**
- Uncommitted changes (always include them)
- Version bump choice (auto-pick MICRO or PATCH — see Step 5)
- CHANGELOG content (auto-generate from commits)
- Commit message approval (auto-commit)
- Multi-file changesets (auto-split into bisectable commits)
- TODOS.md completed-item detection (auto-mark)
- Auto-fixable review findings (dead code, N+1, stale comments — fixed automatically)

---

## Step 1: Pre-flight

1. Check the current branch. If on the base branch, **abort**: "You're on the base branch. Ship from a feature branch."

2. Run `git status` (never use `-uall`). Uncommitted changes are always included — no need to ask.

3. Run `git diff <base>...HEAD --stat` and `git log <base>..HEAD --oneline` to understand what's being shipped.

4. **Detect linked issues.** Scan for issue references in:
   - Branch name (e.g., `fix/123-broken-login`, `feature/GH-45`)
   - Commit messages (`Fixes #123`, `Closes #45`, `Relates to #78`)
   - TODOS.md entries that reference issues
   Collect all issue numbers — they go into the PR body in Step 9.

**Recovery:** If `git status` or `git log` fails (e.g., corrupted index), run `git fsck` and report. Do not proceed.

---

## Step 2: Merge the base branch (BEFORE tests)

Fetch and merge the base branch into the feature branch so tests run against the merged state:

```bash
git fetch origin <base> && git merge origin/<base> --no-edit
```

**If there are merge conflicts:** Try to auto-resolve if they are simple (VERSION, schema, CHANGELOG ordering). If conflicts are complex or ambiguous, **STOP** and show them.

**If already up to date:** Continue silently.

**Recovery:** If `git fetch` fails (network, auth), report the error and **STOP**. If `git merge` fails for reasons other than conflicts (e.g., unrelated histories), report and **STOP**.

---

## Step 3: Run tests (on merged code)

Detect the project's test command from the codebase (package.json scripts, Makefile, Gemfile, etc.) and run it.

**If any test fails:** Show the failures and **STOP**. Do not proceed.

**If all pass:** Continue silently — just note the counts briefly.

**Recovery:** If the test runner itself fails to execute (missing deps, config error), report the error clearly. Do not treat "runner crashed" as "tests passed."

---

## Step 3.5: Pre-Landing Review (delegated to review skill)

Delegate the review to the `/review` skill's checklist rather than duplicating its logic.

1. Read `checklist.md` from the review skill directory (`skills/gstack/review/checklist.md`). **If not found, STOP and report.**

2. Read `design-checklist.md` from the review skill directory (`skills/gstack/review/design-checklist.md`). Keep available for Step 3.5.4.

3. Run `git diff origin/<base>` to get the full diff.

4. Apply the review in two passes per the checklist:
   - **Pass 1 (CRITICAL):** SQL & Data Safety, Migration & Schema Safety, Race Conditions & Concurrency, Auth & Permission Gaps, LLM Output Trust Boundary, Enum & Value Completeness, API Contract Breaking Changes
   - **Pass 2 (INFORMATIONAL):** Error Handling Anti-Patterns, Conditional Side Effects, Magic Numbers & String Coupling, Dead Code & Consistency, LLM Prompt Issues, Test Gaps, Crypto & Entropy, Time Window Safety, Type Coercion at Boundaries, View/Frontend, Performance & Bundle Impact

5. **Check for frontend changes:**
   ```bash
   bash "$CLAUDE_PLUGIN_ROOT/scripts/detect-frontend-files.sh" "$BASE"
   ```
   If any files print, apply the design checklist (loaded in step 2). Check for DESIGN.md in the repo root first — patterns blessed there are not flagged.

6. **Classify each finding as AUTO-FIX or ASK** per the Fix-First Heuristic in the checklist. Critical findings lean toward ASK; informational lean toward AUTO-FIX.

7. **Auto-fix all AUTO-FIX items.** Output one line per fix:
   `[AUTO-FIXED] [file:line] Problem → what you did`

8. **If ASK items remain,** present them in ONE AskUserQuestion:
   - List each with number, severity, problem, recommended fix
   - Per-item options: A) Fix  B) Skip
   - Overall RECOMMENDATION

9. **After all fixes (auto + user-approved):**
   - If ANY fixes were applied: commit fixed files, then **re-run tests** before continuing.
   - If no fixes applied: continue to Step 4.

10. Output summary: `Pre-Landing Review: N issues — M auto-fixed, K asked (J fixed, L skipped)`

Save the review output — it goes into the PR body in Step 9.

---

## Step 3.7: Adversarial review

Dispatch an adversarial reviewer via the Agent tool when the diff meets **ANY** of:
- More than 200 lines changed
- Touches auth, payment, or security-related files
- Introduces new external service integrations
- Contains new cryptographic operations or secret handling

For diffs under 200 lines that don't touch sensitive files, skip this step.

Subagent prompt:
"Read the diff for this branch with `git diff origin/<base>`. Think like an attacker and a chaos engineer. Your job is to find ways this code will fail in production. Look for: edge cases, race conditions, security holes, resource leaks, failure modes, silent data corruption, logic errors that produce wrong results silently, error handling that swallows failures, and trust boundary violations. Be adversarial. Be thorough. No compliments — just the problems. For each finding, classify as FIXABLE (you know how to fix it) or INVESTIGATE (needs human judgment)."

Present findings. FIXABLE findings flow into the Fix-First pipeline (auto-fix, re-run tests if code changed). INVESTIGATE findings are informational only.

Save the adversarial review output — it goes into the PR body in Step 9.

---

## Step 4: Commit (bisectable chunks)

**Goal:** Create small, logical commits that work well with `git bisect`.

1. Group changes into logical commits. Each = one coherent change.

2. **Commit ordering** — use this as a default, adapt to the project structure:
   - **Foundation changes first:** migrations, config, schema, routes, dependencies
   - **Core logic next:** models, services, libraries (with their tests)
   - **Surface layer last:** controllers, views, CLI commands (with their tests)
   - **Metadata always final:** VERSION + CHANGELOG + TODOS.md in the last commit

   For libraries or CLI tools, adapt: core API → internal modules → public interface → metadata.
   For monorepos, group by package rather than layer.

3. **Rules:**
   - A module/service and its test go in the same commit
   - If total diff is small (< 50 lines across < 4 files), a single commit is fine
   - Each commit must be independently valid — no broken imports

4. Compose commit messages: `<type>: <summary>` (feat/fix/chore/refactor/docs)

---

## Step 5: Version bump (auto-decide)

If a `VERSION` file exists:

1. Read the current version.

2. **Auto-decide the bump level based on what changed, not just how much:**

   **MICRO** (auto) — internal-only changes:
   - Bug fixes, typos, comment updates, test-only changes
   - Refactors that don't change public API or behavior
   - Documentation updates

   **PATCH** (auto) — user-fac