github-pr

name	github-pr
description	Prepare, publish, and maintain GitHub pull requests with template-faithful descriptions, fewer pushes, and CI follow-through. Use when creating, updating, pushing, or checking a GitHub PR, or when the user asks to open, ship, publish, or polish a PR.

GitHub PR Workflow

Optimize for a reviewer-friendly PR with low CI noise.

PR Shape

• Use the repository PR template as the source of truth. Preserve its headings, prompts, and checkboxes.
• If there is no template, keep the body compact: summary, verification, risks or rollout notes when relevant.
• Explain reviewer-relevant intent: what changed, why, what to watch. Do not mechanically restate the diff.
• Keep the commit/story shape reviewable. Do not squash, split, reorder, or rewrite existing user commits unless the user agrees.

Push Discipline

• Treat push/open/update as the noisy boundary: it triggers remote checks and may notify reviewers.
• Before the first push, assemble a coherent local commit stack rather than pushing every small fix.
• After CI or review feedback, batch related fixes locally and push them together.
• Ask before pushing or opening/updating a PR unless the user has already explicitly asked for that action.

Context-efficient CI follow-through

When the user explicitly asks to wait, monitor, babysit, or follow through on CI or review:

1. Publish the stable PR head, then hand monitoring to a fresh, compact, read-only thread.
2. Pass only the repository, PR number, expected head SHA, required checks, and automated-review requirements. Do not inherit or reread implementation history.
3. Poll no more than once every 60 seconds and keep each status poll at or below 1,000 output tokens.
4. Do not narrate unchanged state or load coding/domain skills while monitoring.
5. When checks and automated review are green, report the final state and stop.
6. On failure, inspect only the failed job or unresolved review thread and return a concise diagnosis. Do not edit code in the monitor thread.
7. Start a separate fix thread only when the user has authorized further fixes.
8. Do not hardcode a monitor model unless the user explicitly requested one.

Use this monitor prompt as the template:

Monitor PR #<number> in <repository> at expected head <sha>. This is read-only monitoring. Poll checks no more than once per 60 seconds, keep output below 1,000 tokens, and wait for both required checks and automated review. Do not read implementation history or edit code. If green, report the final state. If something fails, inspect only the failed job/review thread and return a concise diagnosis.

Checks

• After pushing or updating a PR, capture the stable head and inspect the current check/review state. Do not declare the PR done while required checks or automated review are pending.
• For explicit wait or follow-through requests, use the context-efficient monitoring workflow above.
• If something fails, use the monitor diagnosis or inspect only the failing check/review thread before changing code.
• When further fixes are authorized, batch related fixes into a coherent commit or commit set, push once, then hand monitoring off again.
• Continue until checks and automated review pass, or stop when the failure is external, blocked by missing access/secrets, or the user asks to pause. Report the concrete blocker and current PR state.