| name | cf-ship |
| description | Verify, commit, push, and create PR. Use when the user wants to ship their work — e.g. "ship it", "push and create PR", "let's ship", "deploy this", "send it", "push my changes", "create a PR", "open a pull request", "ready to merge", "let's get this merged". Also triggers when the user is done with a feature branch and wants the full verify → commit → push → PR workflow. Supports --dry-run to preview without pushing.
|
| created | "2026-02-17T00:00:00.000Z" |
| updated | "2026-07-04T00:00:00.000Z" |
$cf-ship
CLI Requirement: NONE — Works without coding-friend-cli. See CLI requirements for the full matrix.
Ship the current work. Hint: $ARGUMENTS
Workflow
Step 0: Custom Guide & Flags
Custom guide (auto-loaded at invocation — do NOT skip):
bash "${PLUGIN_ROOT}/lib/load-custom-guide.sh" cf-ship
If the block above produced any content, integrate the returned sections: ## Before → execute before Step 1, ## Rules → apply throughout, ## After → after the final step.
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:
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 "${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:
- Run the
$cf-commit workflow (load the cf-commit skill)
- Use
$ARGUMENTS as commit hint if provided
Step 3: Push
git push -u origin <current-branch>
If push fails (e.g., remote ahead), pull first:
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.
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///compare/?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)
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.)
