kaeawc/auto-mobile/push-pr

Push PR

Use this when local work is ready to publish. This is the canonical publish workflow for this repo and replaces the old gh-pr-workflow helper plus any generic github:yeet defaults.

• Prefer push-pr for one branch or one PR.
• Prefer push-my-prs only when the user wants a batch loop across many PRs.
• Use generic plugin publish skills only when this repo-local skill is unavailable.

Workflow

1. Confirm scope before staging.

• Inspect git status --short, git diff --stat, and recent commit style.
• If the worktree contains unrelated or user-owned changes, stage only explicit paths that belong to the PR.
• Use git add -A only when the whole worktree is confirmed in scope.

1. Determine the branch strategy.

• Stay on the current branch when it is already a work branch.
• If publishing from main, master, or the remote default branch, create a repo-appropriate work/... branch unless the user requested a different name.

1. Run the relevant validation before pushing.

• Prefer repo scripts and documented validation commands.
• Do not skip validation unless the user explicitly accepts that risk.

1. Commit intentionally with a repository-appropriate message.

• Keep the commit message terse and descriptive.
• Do not amend or rewrite unrelated commits unless the user explicitly asks.

1. Push the current branch, setting upstream if needed.
2. Create or update exactly one PR.

• Prefer gh pr view --json number,url to detect an existing PR for the current branch.
• If no PR exists, create one with gh pr create.
• If a PR exists, update it with gh pr edit only when the title/body/base needs to change.
• Use the GitHub app for PR creation only when the surrounding tool environment already provides it and the repository, base, and head can be resolved unambiguously; otherwise use gh.

1. Preserve PR body formatting.

• Write multiline PR bodies to scratch/pr-body.md or another temporary body file.
• Use gh pr create --body-file scratch/pr-body.md or gh pr edit --body-file scratch/pr-body.md.
• Avoid --body "..." for multiline Markdown because shell quoting can mangle newlines.

1. Set PR readiness and automerge deliberately.

• Default to a ready PR when the user asked to publish completed work.
• Use a draft PR when the user asks for draft status or the work is intentionally incomplete.
• Enable squash automerge only when that matches the branch's intended workflow and the PR is ready.

1. Summarize branch, commit, PR URL, validation, and any remaining risk.

Repo Rules

• Use github-cli and validate conventions.
• Never use destructive git commands.
• Prefer squash automerge unless the repo or existing PR says otherwise.
• Do not create recurring automations, feedback monitors, reminders, or follow-up cron jobs as part of publishing unless the user explicitly asks for ongoing monitoring.

PR Body Expectations

The PR body should use real Markdown prose and cover:

• what changed
• why it changed
• user or developer impact
• root cause when the PR is a fix
• checks used to validate it