push-pr

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.
2. 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.
3. Run the relevant validation before pushing.
   - Prefer repo scripts and documented validation commands.
   - Do not skip validation unless the user explicitly accepts that risk.
4. 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.
5. Push the current branch, setting upstream if needed.
6. 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`.
7. 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.
8. 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.
9. 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

From kaeawc/auto-mobile, Apache-2.0.

More from kaeawc/auto-mobile