Split Publish

Overview

Use this skill when worktree changes are mixed and the user wants commits separated by task before publishing.

Operating stance: the publish request itself authorizes staging, committing, and pushing the changes it covers. Act on what the request already decides; reserve questions for decisions the request leaves genuinely open, and ask them once, batched, with concrete options. Finish the whole loop rather than stopping after the first group, and lead the final report with the outcome.

Workflow

Follow references/workflow.md for the full procedure and references/grouping-rules.md for the commit-boundary rubric. The core loop:

1. Inspect state first — evidence before any state change: git status -sb, git diff --stat, git branch --show-current, git remote -v. Before staging or committing for a publish, git remote get-url origin and git ls-remote origin must succeed, else stop and report the blocker with the concrete next action. Clean worktree → report nothing to publish and stop.
2. Read local constraints — root AGENTS.md if present, plus branch/release/validation docs relevant to the changed files.
3. Scope from the request — a whole-worktree request sets the scope; a request naming specific work leaves unrelated changes untouched (say what was left out). Never git add -A; stage explicit paths only.
4. Group before staging — one coherent task per commit; order groups so every commit stands on its own; when a file's hunks span groups, split with git add -p/git add -e (non-interactive runs: apply a per-group patch to the index with git apply --cached) or commit under the dominant intent and disclose the rider. Decide clearly defensible groupings and say so; batch the genuinely ambiguous files into one question with concrete options — never group-by-group, never "shall I proceed?".
5. Commit and push one group at a time — verify staged scope (git diff --cached --stat), validate and gate the push on the result, push in order, retry transient network failures up to 4 times with exponential backoff (auth failures are blockers, not retries), and finish every group or report exactly which were pushed and which were not.
6. PRs only on request — no auto-PRs; open a draft PR only when the user asks and the branch is not the default. Prefer repo-native tooling; fallback gh pr create --draft.