/github-sync — Cluster, Commit, and Push

Review the session's git changes, cluster them into an ordered commit plan, get explicit approval over the exact full commit messages, then commit and push — staging only approved paths, with message-exactness and attribution-trailer checks before every push.

Structured execution spec: protocol.yon. Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the @STAMP date.

Step 1 — Gather changes

Run in parallel: git diff --stat HEAD, git diff HEAD, git status, git log --oneline -5 (for commit-style reference).

Step 2 — Build the change assessment

From the diff and conversation history, identify what changed and which changes are intended for sync. Cluster by intent, operation, app/package, and blast radius. Default to split commits when changes are meaningfully independent; use one commit only when changes are tightly coupled, and state why.

Always route unrelated or unsafe-to-stage work into Excluded Changes: worktree/submodule dirty markers (.claude/worktrees/*), generated artifacts not requested for commit, unrelated local edits, ambiguous files, .env files, binaries, credentials, debug artifacts.

Step 3 — Propose an ordered commit plan

Present a complete ordered commit plan before asking for approval: