ship

What this skill does

You are automating the complete git workflow to ship code changes. After creating the PR, you will automatically review it, fix any issues, and merge it. The user may provide a branch name and description as arguments: $ARGUMENTS

## Pre-loaded Context

The following git state is injected before Claude processes this prompt:

**Working tree status:**
!`git status -s`

**Diff summary:**
!`git diff --stat`

**Staged diff summary:**
!`git diff --cached --stat`

**Current branch:**
!`git branch --show-current`

**Remote:**
!`git remote -v`

**Diff size (lines changed):**
!`git diff --stat | tail -1 | awk '{print $NF}'`

## Proactive Triggers

Suggest this skill when:
1. User says "done", "ready to ship", "push this", "let's ship it", or similar completion phrases
2. After completing a work item from an implementation plan
3. After all tests pass and changes are ready
4. User asks to create a PR or push changes
5. After a code review cycle is complete and changes are approved

## Destructive Action Warning

This skill modifies git state (creates branches, commits, pushes, and merges). Before proceeding:
- Confirm the user intends to ship the current changes
- Never force-push or push to main/master directly
- Always create a feature branch for changes
- If the working directory has uncommitted changes that look unrelated, ask before staging everything

## Input Validation

**Optional Arguments:**
- `<branch-name>` - Custom branch name (default: auto-generated from changes)
- `draft` - Create PR as draft
- `--dry-run` - Preview all operations without making any changes
- `--audit` - Log all git and PR operations to `.claude-plugin/audit.log` (see common-patterns.md)

**Dry-Run Mode:**
When `--dry-run` is specified:
- Show what branch name would be created
- Show what files would be staged and committed
- Show the proposed commit message
- Show the PR title and body that would be created
- Prefix all output with `[DRY-RUN]` to clearly indicate preview mode
- Do NOT execute any git commands that modify state (checkout, add, commit, push, pr create)

**Audit Mode:**
When `--audit` is specified:
- Log every git and PR operation to `.claude-plugin/audit.log`
- Each log entry is a JSON line with: timestamp, command, action, details, success
- Create `.claude-plugin/` directory if it doesn't exist
- Append to log file (never overwrite existing entries)

Example log entries:
```json
{"timestamp": "2026-01-14T10:30:00Z", "command": "ship", "action": "git_checkout", "details": {"branch": "feat/new-feature"}, "success": true}
{"timestamp": "2026-01-14T10:30:01Z", "command": "ship", "action": "git_commit", "details": {"sha": "abc1234", "message": "feat: add new feature"}, "success": true}
{"timestamp": "2026-01-14T10:30:02Z", "command": "ship", "action": "git_push", "details": {"remote": "origin", "branch": "feat/new-feature"}, "success": true}
{"timestamp": "2026-01-14T10:30:03Z", "command": "ship", "action": "pr_create", "details": {"number": 42, "url": "https://github.com/..."}, "success": true}
{"timestamp": "2026-01-14T10:30:30Z", "command": "ship", "action": "pr_merge", "details": {"number": 42, "strategy": "squash"}, "success": true}
```

## Pre-flight Checks

Use the pre-loaded context injected above — do NOT re-run these git commands:

1. **Verify git repository** — remote output above will be empty if not a git repo; abort if so
2. **Confirm uncommitted changes** — check the injected `git status -s` and diff summaries; if both are empty, abort with a clear message
3. **Confirm current branch** — check the injected branch name; if not `main`, ask the user if they want to proceed from the current branch or abort
4. **Diff size gate** — check the injected "Diff size (lines changed)" value. If > 500, note this for Phase 6 (will suggest `/ultrareview` instead of standard review)

## Phase 0: Platform Detection

Detect the git hosting platform and select the appropriate CLI:

1. Parse the injected `git remote -v` output (pre-loaded above) for the push remote URL — do NOT re-run the command
2. **If URL contains `github.com`** → set `PLATFORM=github`
   - Verify `gh auth status` succeeds
   - If `gh` is not installed or not authenticated, abort with install/auth instructions
3. **Otherwise** → set `PLATFORM=gitea`
   - Verify `tea login list` shows a login matching the remote URL's host
   - If `tea` is not installed, abort with: `Install tea CLI: https://gitea.com/gitea/tea`
   - If no matching login exists, abort with: `Run: tea login add --url <host-url> --name <name> --token <token>`
4. Store the platform choice for all subsequent steps
5. Display: `Platform detected: [GitHub|Gitea] (using [gh|tea] CLI)`

**Draft PR limitation:** The `tea` CLI does not support `--draft` for PR creation. When the `draft` argument is passed on a Gitea repo, warn the user that draft PRs are not supported on Gitea and create a normal PR instead.

## Execution Steps

### Phase 1: Determine Branch Name
- If the user provided a branch name in arguments, use it
- If not, analyze the staged/unstaged changes and generate a descriptive kebab-case branch name (e.g., `fix-login-validation`, `add-user-export-feature`)
- Confirm the branch name with the user before proceeding

### Phase 2: Create and Switch to New Branch
```bash
git checkout -b <branch-name>
```

### Phase 3: Documentation Gate, Stage, and Commit

#### 3.1: Documentation Gate

Before staging changes, verify project documentation is current. **LAB_NOTEBOOK.md is a hard gate** — do not proceed to staging until notebook requirements are met.

**LAB_NOTEBOOK.md (Hard Gate):**

1. Check if `LAB_NOTEBOOK.md` exists in the project root
2. If it does NOT exist — skip this gate entirely
3. If it exists:
   a. Read the project's `CLAUDE.md` AND the system-level `~/.claude/CLAUDE.md` for lab notebook rules — the project's CLAUDE.md contains the "Lab Notebook — MANDATORY Logging Protocol" section with the project's logging rules, entry template, and project-specific tags; the system CLAUDE.md may contain additional constraints
   b. Read the latest entries in `LAB_NOTEBOOK.md` (the Experiment Log section)
   c. Analyze the current changes using the pre-loaded diff summaries injected at the top of this prompt (do NOT re-run `git diff` or `git diff --cached` — use the injected output)
   d. Determine if there's a current entry covering the changes being shipped:
      - An entry dated today whose objective relates to the changes
      - An IN PROGRESS entry that covers the current work
   e. **If no current entry exists** — create one:
      - Add a new entry following the notebook's template (next sequential Entry number)
      - Include: Date, Environment (from recent entries or system context), Objective (derived from the changes), Status: COMPLETE
      - Summarize what was done in Actions & Results
      - For Hypothesis: reconstruct from the changes — what was the expected outcome?
      - For Rollback Plan: reference the git SHA before the changes (`git rev-parse HEAD`)
      - Update the Decision Log and Action Items tables at the top if applicable
   f. **If a current entry exists but is IN PROGRESS** — close it out:
      - Update the entry: add final results, set Status to COMPLETE
      - Fill in Duration if empty
      - Update What Worked / What Failed based on outcomes
   g. Notebook updates will be included in the commit at step 3.2

**Other Documentation (Soft Warnings — non-blocking):**

Scan for documentation that may need attention. Report but do NOT halt:
- `CHANGELOG.md` — warn if it exists and changes include new features or breaking changes
- `README.md` — warn if changes add new user-facing features, commands, or endpoints

Display results before proceeding:
```text
Documentation Gate:
  LAB_NOTEBOOK.md: [Updated entry E{NNN} | Created entry E{NNN} | Not found (skipped) | Current (no update needed)]
  Warnings: [list, or "None"]
```

#### 3.2: Stage and Commit

- Stage all changes (including any notebook updates