/push

description: Commit, push, and post a progress comment using session context or branch detection
argument-hint: [context]
allowed-tools: Bash, Read, Grep, Glob

Push

You are finalizing a batch of work: committing changes, pushing to remote, and documenting progress on the associated PR or issue.

Step 1: Determine What to Commit

Run `git status` and `git diff --staged` to understand the current state.

**Staging logic:**

• If you have context from this session about which files you modified, stage those specific files. Do NOT use `git add -A` or `git add .` — add files by name.
• If files are already staged and the staging looks correct based on session context, proceed with those.
• If it is unclear what should be staged (e.g., this is a fresh session with no prior context), review all untracked and unstaged files, present your findings to the user, and ask for guidance on what to stage.
• Never stage files that likely contain secrets (.env, credentials.json, etc.).

Step 2: Commit

Review recent commit messages for style consistency:

git log --oneline -10

Generate a commit message that:

• Follows the repository's existing commit message style
• Summarizes the nature of the changes (new feature, bug fix, refactor, etc.)
• Focuses on the "why" rather than the "what"
• If context was provided ($ARGUMENTS): if it reads like a commit message, use it verbatim; otherwise, treat it as guidance for commit message generation. Context may also inform the progress comment (Step 4) and next-step suggestions (Step 5).

Create the commit. Use a HEREDOC for the message to ensure proper formatting:

git commit -m "$(cat <<'EOF'
Commit message here.

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

Step 3: Push

Push to the remote tracking branch:

git push

If no upstream is set, push with `-u` flag to the current branch name.

Step 4: Post Progress Comment

Determine the associated PR or issue using the following priority order:

1. Session context (primary)

Check the current conversation for signals about what the user has been working on. If an earlier command in this session targeted a specific issue or PR, use that as the comment target.

**Issue-oriented signals** — post on the issue:

• `issue-implement` was invoked with an issue number
• `issue-assessment` was invoked with an issue number
• `issue-plan` was invoked with an issue number
• `issue-plan-review` was invoked with an issue number

**PR-oriented signals** — post on the PR:

• `pr-review-fix` was invoked with a PR number
• `pr-ci-fix` was invoked with a PR number
• `pr-review` was invoked with a PR number
• `pr-pre-merge` was invoked with a PR number

If session context points to an issue but a PR also exists on the current branch (`gh pr view --json number,url` succeeds), prefer the PR -- it supersedes the issue as the active work context.

If you can identify a specific target from earlier in this conversation, use it directly: `gh issue comment <number>` or `gh pr comment <number>`. Skip to the Comment content section below.

2. Detection fallback

If session context is ambiguous or unavailable (e.g., fresh session, standalone push):

1. **Try PR first:** Run `gh pr view --json number,url` on the current branch. If a PR exists, comment on it. 2. **Fall back to issue:** If no PR, check the branch name for an issue number pattern (e.g., `feature/issue-55-*` or `fix/issue-23-*`). If found, comment on that issue.

3. Skip gracefully

If neither session context nor detection yields a target, skip commenting and inform the user.

Comment content

Post a reply comment documenting what was done:

• Brief summary of changes in this batch
• Commit hash(es) included
• Any notable decisions or deviations from the plan

When referring to numbered items (findings, suggestions, stages) in the comment body, use plain words like "finding 3" or "suggestion 3" -- not `#<number>` notation, which GitHub auto-links to issues/PRs.

Step 5: Confirm

Report to the user in CLI output (do NOT include next-step suggestions in the GitHub comment from Step 4):

• What was committed (files and message)
• Where it was pushed
• Where the progress comment was posted (with link)

**Next-step suggestions** (always prefixed with `/clear`):

First, determine the default branch:

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

• **If on the default branch:** Suggest issue-oriented next steps (e.g., "Next: `/clear` then `/mach10:issue-assessment $ISSUE`" or "Next: `/clear` then `/mach10:issue-implement $ISSUE next-stage`"). Do not suggest `/mach10:pr-create` or `/mach10:pr-review`.
• **If on a feature branch**, apply these checks in order:

1. **PR exists** (`gh pr view --json number` succeeds): Suggest "Next: `/clear` then `/mach10:pr-review $PR`". Stop here -- plan detection is irrelevant once a PR exists.

2. **Session context provides stage info**: If `issue-implement` was invoked earlier in this session, you already know the issue number, stage number (or range), and total stage count from reading the plan. Use this directly:

• If more stages remain (next stage = current + 1, or last-in-range + 1 for multi-stage invocations like `stages 3-4`): Suggest "Next: `/clear` then `/mach10:issue-implement <issue> <next-stage>`".
• If the current stage was the last: Suggest "Next: `/clear` then `/mach10:pr-create`".

3. **No session context (fresh session)**: If no `issue-implement` context is available, attempt a lightweight plan lookup:

• Determine the issue number from Step 4's resolved target (or from the branch-name issue-number pattern if Step 4 did not resolve one).
• If an issue number is available, run `gh issue view <issue-number> --comments` and search for the `<!-- mach10-plan -->` marker (use the last match if multiple exist).
• If a plan is found, count stages by matching `^##+ Stage \d+` headings (ignore stage references in prose para