Git Ship

Git Ship Skill

Full cycle for ai-dial-chat: checkout new branch from development → stage → commit (Conventional Commits) → push → optional PR. Base branch is development.

Supporting files (read them when the step says so — don't inline everything up front):

• .agents/skills/git-ship/areas.md — how to resolve the commit area (scope) for this repo.
• .agents/skills/git-ship/examples/commit-messages.md — type table, message + branch examples.
• .agents/skills/git-ship/examples/pr-body.md — PR body template, rules, and gh pr create usage.

Step 0 — Detect mode (new branch vs. update existing)

git rev-parse --abbrev-ref HEAD                 # current branch
gh pr view --json number,url,state 2>/dev/null  # open PR for current branch (if any)

• New-branch mode — current branch is development (or another base branch), or there's no PR for it. Run the full cycle: Steps 1–6.
• Update-existing mode — you're already on a feature branch and it has an open PR (or the user says "push to the existing PR" / "update my PR"). Do not create a new branch and do not run gh pr create. Stay on the current branch, then:
  1. Step 2 — review the changes.
  2. Step 4 — generate the commit message (reuse the existing PR's ticket; keep the same area/type).
  3. Step 5 — skip the git checkout lines; just git add → git commit → git push.
  4. Skip Step 6's gh pr create. Pushing updates the open PR automatically. Only refresh the body (gh pr edit --body) if the user asks or the description is stale/missing.
  5. Step 7 — report the existing PR link, not a new one.

Step 1 — Gather required context

• Ticket number — use the ticket argument if passed. Else look in conversation context. If still not found, ask: "What is the ticket number?"
• Area — if the area argument is passed, use it directly in Step 3.
• Draft PR? — if the user said "draft", note it for Step 6.

This skill runs in a forked context (context: fork), so it does not see the main conversation. Prefer passing arguments: /git-ship 7432 catalog.

Step 2 — Understand the changes

git status
git diff HEAD

If there are no changes at all — report and stop.

Step 3 — Determine area

If the area argument was given, use it. Otherwise read .agents/skills/git-ship/areas.md and map the changed files to an area using its resolution rules. If the resolved area is new, follow that file's append-only self-extend rules so the taxonomy grows (the edit is staged in Step 5 and ships in the same commit).

Step 4 — Generate commit message

Format: <type>(<area>): <short description> (Issue #<ticket>).

Read .agents/skills/git-ship/examples/commit-messages.md for the type table, message examples, and the branch-name rule. Analyze the diff to pick the most accurate type and write a concise, imperative description. Breaking change → add ! before the colon.

Step 5 — Execute

# 1. Create branch from base (skip in update-existing mode)
git checkout development
git checkout -b <type>/<short-slug>

# 2. Stage all changes (includes any areas.md self-extend edit)
git add .

# 3. Commit
git commit -m "<type>(<area>): <description> (Issue #<ticket>)"

# 4. Push
git push origin <type>/<short-slug>

If push fails (no permissions, rejected, conflict) — report the full output and stop. Do not force push or rebase automatically.

Step 6 — Pull Request (if requested)

If the user requested a PR or draft PR, read .agents/skills/git-ship/examples/pr-body.md and follow the repo PR template (.github/pull_request_template.md) — fill every placeholder, then run the gh pr create command shown there with --base development.

Step 7 — Summary

Always finish with a concise confirmation:

Branch:  <type>/<short-slug>
Commit:  <type>(<area>): <description> (Issue #<ticket>)
Push:    ✅ succeeded  /  ❌ failed — <reason>
PR:      <link> (created)  /  <link> (updated existing)  /  skipped
Area:    <area>  (note "added to taxonomy" if Step 3 self-extended areas.md)