dinhanhthi /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 "<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-commitworkflow (load thecf-commitskill) - Use
$ARGUMENTSas 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:
ghCLI 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.)