/arn-code-ship

name: arn-code-ship
description: >-
  This skill should be used when the user says "ship it", "arness code ship",
  "create PR", "open pull request", "push and PR", "commit and push",
  "wrap up", "ship the feature", "ship the fix", "ready to ship",
  "push changes", "finalize", "finish up", or wants
  to commit, push, and optionally open a pull request. Guides through branching,
  staging, committing with meaningful messages, pushing, and PR creation.
  Works standalone or as the final Arness pipeline step. Do NOT use this for
  reviewing PRs — use /arn-code-review-pr for that.
version: 1.3.1

Arness Ship

Guides through branching, staging, committing, pushing, and optionally opening a pull request. Works standalone or as the final step in the Arness pipeline.

Pipeline position:

arn-code-review-implementation -> arn-code-document-project -> **arn-code-ship**

This skill handles the entire shipping workflow: verifying git state, ensuring the user is on the right branch, staging changes safely, generating meaningful commit messages, pushing, and creating a pull request via the GitHub CLI or Bitbucket CLI.

Workflow

Step 1: Check Git State

Check `## Arness` config in CLAUDE.md for `Git: yes`. If not present, run runtime check: `git rev-parse --is-inside-work-tree`.

If Git is not available, inform the user: "This project is not a git repository. `/arn-code-ship` requires Git." and exit.

Read the **Platform** field from `## Arness` config in CLAUDE.md (values: `github`, `bitbucket`, or `none`). Store this value for use in Step 5. If the `Platform` field is not present, fall back to legacy detection: check for `GitHub: yes` and treat as `github`; otherwise treat as `none`.

Gather current state:

• Current branch: `git branch --show-current`
• Uncommitted changes: `git status --short` (never use `-uall`)
• Commits ahead of main: `git log main..HEAD --oneline` (skip if on main)
• Remote tracking: `git rev-parse --abbrev-ref @{upstream}` (may fail if no upstream)

If no uncommitted changes AND no commits ahead of remote, inform the user: "Nothing to ship — working tree is clean and up to date with remote." and exit.

---

Step 2: Branch Decision

**If on main/master:**

• Warn the user: "You're on the main branch. It's recommended to create a feature branch before shipping."
• Offer to create a new branch:
• If Arness context is available (current spec or plan), suggest a name derived from it (e.g., `feat/websocket-support`, `fix/checkout-500-error`)
• Otherwise ask the user for a branch name
• Create with `git checkout -b <branch-name>`
• Let the user continue on main if they prefer

**If on a feature branch:**

• Confirm: "You're on branch `<branch-name>`. Proceeding."

---

Step 3: Stage and Commit

1. Show current changes: run `git status --short` and `git diff --stat` 2. Check for sensitive files in the diff — warn if any match common patterns:

• `.env`, `.env.*`
• Files containing `credential`, `secret`, `token`, `password`, `key` in their name
• `id_rsa`, `*.pem`, `*.key`

3. **Lint and Format Gate.** Read the `Linting:` field from CLAUDE.md `## Arness` block:

• If `Linting: none` or `Linting: skip` (or the field is missing) — skip this sub-step silently and proceed to staging.
• If `Linting: enabled`:

1. Read `<code-patterns-dir>/linting.md` (the per-service detection produced by `arn-code-codebase-analyzer`, covering both linters and formatters). 2. Compute the staged diff scope: `git diff --name-only HEAD` (or against the base branch if uncommitted changes are not yet staged — fall back gracefully). 3. For each section in `linting.md` whose `Scope hint` intersects the diff, invoke the section's `Discovered check command` against the changed files within that scope. The discovered command MUST be a check-only invocation per the analyzer contract — never run a mutation/write command as the gate. When the underlying tool supports per-file invocation, narrow accordingly; otherwise run as-is. 4. Aggregate results across all invocations: total issue count `N`, broken down by `kind` (lint vs format) and severity (error/warning/info), and per service. 5. **If `N == 0`:** print a one-line confirmation ("Lint and format clean: 0 issues across <services>.") and proceed to staging. 6. **If `N > 0`:** show the breakdown (per-service counts, lint vs format totals, severity totals). Determine the suggested default:

• `N <= 20` → suggest **Fix now**
• `N > 20` → suggest **File a backlog issue**

Then ask (using `AskUserQuestion`):

> **Found N issues across \<comma-separated services\> (\<L\> lint, \<F\> format). Suggested: \<Fix now | File a backlog issue\>. How would you like to proceed?** > 1. **Fix now** — pause shipping, address the issues, then return > 2. **File a backlog issue and proceed** — record the issues for later, proceed with commit > 3. **Proceed with documented reason** — annotate the commit message with rationale, proceed without filing a backlog issue

Apply the choice:

• **(1) Fix now** — exit `arn-code-ship`. Tell the user: "Run your linter or formatter, fix the issues, then re-run `/arn-code-ship` when ready." Do not commit. (Note: format violations are usually auto-fixable via the project's write-mode formatter command, but this skill never invokes mutation commands itself.)
• **(2) File a backlog issue and proceed** — read the `Issue tracker` field from `## Arness`. For `github`: `gh issue create --title "Lint/format backlog: N issues from <branch>" --body "<output summary including lint vs format breakdown>"`. For `jira`: use the Atlassian MCP server to create the issue with the same title and body. For `none`: warn the user that no issue tracker is configured and fall back to choice (3). Then proceed to staging.
• **(3) Proceed with documented reason** — prompt the user for a one-line rationale. Append "L