Cf Ship

---
name: cf-ship
description: >
  Verify, commit, push, and create a PR. Triggers: "ship it", "push and create PR", "let's
  ship", "create a PR", "open a pull request", "ready to merge". Supports --dry-run.
created: 2026-02-17
updated: 2026-09-27
---

# /cf-ship

Ship the current work. Hint: **$ARGUMENTS**

## Workflow

### Step 0: Custom Guide & Flags

```!
bash "<plugin-root>/lib/load-custom-guide.sh" cf-ship
```

If the block above printed anything, apply only the `## Before`, `## Rules`, and `## After` sections; if it shows the raw command instead of output, re-run that exact `load-custom-guide.sh` fence now.

**Guard — do NOT short-circuit:** If a `## Before` section was injected above, you MUST carry it out before ANY assessment of whether there is something to ship. A clean working tree or being on `main` does NOT by itself mean "nothing to ship" — a `## Before` guide may still require action (e.g. a version-bump / tag / release flow). Never conclude "nothing to ship" until Step 0's `## Before` has been executed.

**Dry-run check**: If `$ARGUMENTS` contains `--dry-run`, enter simulation mode — run all steps below but **do not execute** any destructive action (no commit, no push, no PR creation). Prefix each step's output with `[dry-run]` and show what **would** happen. At the end, print:

```
🏃 DRY RUN COMPLETE — nothing was pushed or created.
```

### Step 1: Verify

Load the `cf-verification` skill and run the full checklist:

- [ ] Tests pass
- [ ] Build succeeds
- [ ] Linter clean
- [ ] No console errors

If ANY check fails, stop and fix before proceeding.

**Capturing out-of-scope side-effects:** If verification surfaces a problem **unrelated to the work being shipped** that is non-trivial (fixing it inline would block or expand this ship), do NOT fix it now. Record it for later, then continue the ship workflow:

```bash
bash "<plugin-root>/lib/capture-later.sh" \
  --name "<short title>" --description "<what & where — enough to act on cold>" \
  --source cf-ship [--slug <task/plan slug, if one exists>] [--problem "<what is being shipped>"]
```

This writes `<docsDir>/later/YYYY-MM-DD-<name>.md` with frontmatter (slug, problem, conversation_id) as an in-repo audit trail. Genuine blockers that make the ship unsafe should still stop the workflow, not be deferred.

### Step 2: Commit

If there are uncommitted changes:

1. Run the `/cf-commit` workflow (load the `cf-commit` skill)
2. Use `$ARGUMENTS` as commit hint if provided

### Step 3: Push

```bash
git push -u origin <current-branch>
```

If push fails (e.g., remote ahead), pull first:

```bash
git pull --rebase origin <current-branch>
git push
```

### Step 4: Create PR (if on a feature branch)

**Guard:** If current branch is `main` or `master`, warn the user and skip this step — do NOT push directly to the main branch.

Try `gh` first, fall back to a manual link if `gh` is not installed:

**PR title:** Use conventional commit style, under 70 chars. Derive from the commit(s) on the branch.

```bash
gh pr create --title "<type>(<scope>): <summary>" --body "<body>"
```

If `gh` is not available, tell the user to create the PR manually and provide the URL:

> `gh` CLI not found. Please create a PR manually:
> https://github.com/<owner>/<repo>/compare/<branch>?expand=1

PR body template:

```
## Summary
<1-3 bullet points describing the changes>

## Test plan
- [ ] Tests pass
- [ ] Manual verification done
```

### Step 5: Report

Show the user:

- Commit SHA
- Push result
- PR URL (if created)

After a minor/major release, suggest `/cf-showcase` to refresh the project's intro video or poster (suggestion only, never auto-invoke).

## Rules

- NEVER force push unless explicitly asked
- NEVER push to main/master directly
- ALWAYS verify before pushing
- Ask user before pushing if there are concerns
- NEVER include AI/agent attribution in commits or PRs (no "Co-Authored-By", "Generated by", "Claude", "Copilot", "AI-assisted", etc.)