file-a-pr

name	file-a-pr
description	Files one concise GitHub pull request from a completed change. Use when the user explicitly asks to file, open, create, or update a PR from the current branch.
disable-model-invocation	true
argument-hint	Optional base branch and draft or ready preference

File a PR

Publish one completed change as a reviewer-ready PR, then stop. Use pull-request for later review, CI, conflict, or merge work.

Authority

A filing request authorizes scoped verification, commits, an ordinary push, and creating the PR or replacing the title and body of the same branch's existing PR. Stage explicit paths and preserve ambient changes.

Comments, review requests, optional metadata, merging, deployment, rebasing, force-pushing, and history rewriting require separate consent. Repository-required publication metadata is part of filing.

File the PR

1. Resolve the repository, branch, base, worktree ownership, dirty state, exact diff, repository instructions, and PR template. Update an existing PR for this branch; stop on uncertain ownership, secrets, inseparable changes, or overlap with another PR.
2. Reconcile the diff and commits with the original goal, or infer the goal from the linked task and existing PR while naming that limit. Use code-review; a finding that changes behavior, risk, scope, or the review decision requires a draft unless publication itself is unsafe.
3. Verify the source head with the narrowest relevant checks. Link current proof. If a preview tests a synthetic merge commit, record both SHAs; qualify claims without linked or independently verified evidence.
4. Follow repository title conventions, otherwise use a concise conventional-commit title naming the outcome. Use engineering-writing and the PR body rule below.
5. Commit scoped files if needed, push normally, and create or update the PR. Use draft state while checks, changed paths, temporary pins, migration order, or hard dependencies remain unresolved; otherwise follow user intent and repository convention, defaulting to ready.
6. Re-fetch the PR and verify its URL, base, head, title, body, and draft state. Return the URL, state, current-head proof, blockers, skipped checks, and actions still needing consent.

PR body

Lead with one or two sentences that state the changed behavior and why it matters. Prefer this complete explanation over a Summary inventory:

Changes live incoming Teams author hydration to ctx.api.conversations.getMemberById, so the normal path no longer requires Microsoft Graph's User.Read.All permission or tenant admin consent. Explicit getUser() lookups remain Graph-backed.

When those sentences explain the change, continue directly to the repository-required test plan or checklist. Add a section only when it changes the review decision, such as a migration step, a remaining limitation, a before-and-after comparison, or a contract with several distinct cases. Use the smallest form that makes that evidence clear.