Claude Skill

ship

Commit, push, and optionally create or update a PR for the current staged changes. Use when the user asks to "ship", "ship it", "ship changes", "commit push and PR", or "ship this".

LLM Mart · 0 points · 21 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download tobihagemann-turbo-claude_skills_ship-6de19b6.zip · 1 KB
Part of tobihagemann/turbo — 147 skills

Install

skills CLI npx skills add https://github.com/tobihagemann/turbo/tree/main/claude/skills/ship
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install tobihagemann-turbo@llmmart
Git git clone https://github.com/tobihagemann/turbo.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole tobihagemann/turbo collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Ship

Commit, push, and optionally create or update a PR for the current staged changes.

Task Tracking

At the start, use TaskCreate to create a task for each phase:

  1. Determine intent
  2. Branch (if needed)
  3. Stage unstaged changes
  4. Run /commit-rules skill
  5. Commit
  6. Push (if requested)
  7. Create or update PR (if requested)

Step 1: Determine Intent

Detect the repository state:

  • Default branch: gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
  • Current branch name, and whether it tracks an upstream
  • Whether a PR already exists for the current branch (gh pr view)

Sample the prevailing workflow from recent default-branch history (git log --first-parent origin/<default-branch> -n 30 --pretty=%s): judge whether changes mostly land through pull requests (merge-PR commits or (#N)-suffixed squash commits) or are committed directly to the default branch.

Output a one-line summary of the detected state as text. Then use AskUserQuestion to choose how to proceed, offering these options:

  • Commit, push, and create/update the PR — say "create a PR" when no PR exists for the current branch and "update the PR" when one does; on the default branch, Step 2 creates a feature branch first
  • Commit and push — commit, then push to the current branch's remote
  • Commit only — commit the staged changes, do not push

Recommend the option that fits this repo by listing it first and labeling it (Recommended): when the current branch already has a PR, recommend updating it; otherwise follow the prevailing workflow — recommend the PR path for a PR-based history, or commit and push for a direct-commit history.

If the user declines (chooses the free-form "Other" option or asks to abort), leave the changes staged and do not commit.

Step 2: Branch (if Needed)

If the chosen option creates a PR and the current branch is the default branch:

  1. Suggest a branch name based on the changes and use AskUserQuestion to confirm or adjust
  2. Create and switch to the new branch: git checkout -b <branch-name>

Step 3: Check for Unstaged Changes

Run git status to check for unstaged changes. Stage by path the files that belong to the current changeset, using git add -p <file> for one that also carries unrelated changes. This catches files modified by auto-formatters that were not re-staged.

Step 4: Run /commit-rules Skill

Run the /commit-rules skill to load commit message rules and technical constraints.

Step 5: Commit

Commit the already-staged changes (do not stage additional files) with a message following the loaded rules. Keep the branch Step 2 left in place and commit on it, including when that is the default branch.

If the commit fails due to a pre-commit hook (formatter, linter), fix the issues — or run the project's format/lint script to auto-fix — then re-stage by path the files the hook modified before retrying. Pre-commit hooks may modify files in the working tree without updating the staging area.

Step 6: Push (if Requested)

If the chosen option includes pushing, push to the current branch's remote:

git push

Step 7: Create or Update PR (if Requested)

  • Create PR — run the /create-pr skill
  • Update PR — run the /update-pr skill

When /create-pr hands the body file over for editing instead of posting, report that path and that no PR was opened.

Then use the TaskList tool and proceed to any remaining task.

Rules

  • Run the /commit-rules skill before every commit; do not commit without loading it first.
  • Never stage or commit files containing secrets (.env, credentials, API keys). Warn if detected.
  • Don't reference .turbo/ content (filenames, acceptance criteria, step numbers, headings) in branch names. .turbo/ is gitignored, so these references would be opaque to anyone reading without local copies.
Files (turbo)
  • SKILL.md 4 KB
    ---
    name: ship
    description: "Commit, push, and optionally create or update a PR for the current staged changes. Use when the user asks to \"ship\", \"ship it\", \"ship changes\", \"commit push and PR\", or \"ship this\"."
    ---
    
    # Ship
    
    Commit, push, and optionally create or update a PR for the current staged changes.
    
    ## Task Tracking
    
    At the start, use `TaskCreate` to create a task for each phase:
    
    1. Determine intent
    2. Branch (if needed)
    3. Stage unstaged changes
    4. Run `/commit-rules` skill
    5. Commit
    6. Push (if requested)
    7. Create or update PR (if requested)
    
    ## Step 1: Determine Intent
    
    Detect the repository state:
    
    - Default branch: `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'`
    - Current branch name, and whether it tracks an upstream
    - Whether a PR already exists for the current branch (`gh pr view`)
    
    Sample the prevailing workflow from recent default-branch history (`git log --first-parent origin/<default-branch> -n 30 --pretty=%s`): judge whether changes mostly land through pull requests (merge-PR commits or `(#N)`-suffixed squash commits) or are committed directly to the default branch.
    
    Output a one-line summary of the detected state as text. Then use `AskUserQuestion` to choose how to proceed, offering these options:
    
    - **Commit, push, and create/update the PR** — say "create a PR" when no PR exists for the current branch and "update the PR" when one does; on the default branch, Step 2 creates a feature branch first
    - **Commit and push** — commit, then push to the current branch's remote
    - **Commit only** — commit the staged changes, do not push
    
    Recommend the option that fits this repo by listing it first and labeling it `(Recommended)`: when the current branch already has a PR, recommend updating it; otherwise follow the prevailing workflow — recommend the PR path for a PR-based history, or commit and push for a direct-commit history.
    
    If the user declines (chooses the free-form "Other" option or asks to abort), leave the changes staged and do not commit.
    
    ## Step 2: Branch (if Needed)
    
    If the chosen option creates a PR and the current branch is the default branch:
    
    1. Suggest a branch name based on the changes and use `AskUserQuestion` to confirm or adjust
    2. Create and switch to the new branch: `git checkout -b <branch-name>`
    
    ## Step 3: Check for Unstaged Changes
    
    Run `git status` to check for unstaged changes. Stage by path the files that belong to the current changeset, using `git add -p <file>` for one that also carries unrelated changes. This catches files modified by auto-formatters that were not re-staged.
    
    ## Step 4: Run `/commit-rules` Skill
    
    Run the `/commit-rules` skill to load commit message rules and technical constraints.
    
    ## Step 5: Commit
    
    Commit the already-staged changes (do not stage additional files) with a message following the loaded rules. Keep the branch Step 2 left in place and commit on it, including when that is the default branch.
    
    If the commit fails due to a pre-commit hook (formatter, linter), fix the issues — or run the project's format/lint script to auto-fix — then **re-stage by path the files the hook modified** before retrying. Pre-commit hooks may modify files in the working tree without updating the staging area.
    
    ## Step 6: Push (if Requested)
    
    If the chosen option includes pushing, push to the current branch's remote:
    
    ```bash
    git push
    ```
    
    ## Step 7: Create or Update PR (if Requested)
    
    - **Create PR** — run the `/create-pr` skill
    - **Update PR** — run the `/update-pr` skill
    
    When `/create-pr` hands the body file over for editing instead of posting, report that path and that no PR was opened.
    
    Then use the TaskList tool and proceed to any remaining task.
    
    ## Rules
    
    - Run the `/commit-rules` skill before every commit; do not commit without loading it first.
    - Never stage or commit files containing secrets (`.env`, credentials, API keys). Warn if detected.
    - Don't reference `.turbo/` content (filenames, acceptance criteria, step numbers, headings) in branch names. `.turbo/` is gitignored, so these references would be opaque to anyone reading without local copies.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related