--- name: git-pr description: Create or publish the current branch GitHub pull request, or do one explicitly ordered conflict/base update, through pi_git_pr with bounded authority. --- # git-pr Use `pi_git_pr` after the user authorizes pull request (PR) creation, publication, or an explicit conflict/base update. The default `scope: "publication"` keeps creation and local publication separate from base updates. It stops before feedback, continuous integration (CI) repair, base updates, CI waiting, or merge. `/pr` remains the separate full-lifecycle command. Select the intended worktree with `projectPath` on `pi_git_pr`. It can name the worktree or a directory inside it. Relative paths start at the session directory; omission uses that directory without searching child repositories. If the repository is unclear, ask instead of choosing a sibling. Pass the canonical `projectPath` from the workflow instructions on every helper call. Use it for local file work and pass it to any delegated worker. A path cannot transfer a run between worktrees or sessions. From a non-Git parent, the user can run `/pr ` for the full lifecycle. For an explicit conflict/base-update order, use `scope: "update-branch"`. Supply `base` only if the user named it, and omit `allowUpstream`. This scope permits bounded refresh, one guarded update and its checked publication, then stops. It cannot create, link, sync local history, publish unrelated work, sweep feedback, repair CI, or merge the PR. A configured, open, non-draft current PR and a clean branch at the published head are required, except for matching verified update recovery. Report blockers; do not widen the scope or ask for `/pr` merely to do this update. Main owns conflict decisions; do not delegate them. If publication will be delegated, delegate **before** starting a workflow. Give the child the authorized work scope, explicit base intent, and repository-local upstream consent, not a parent `runId`. The child must call `pi_git_pr` and follow its own same-session skill handoff. Run IDs are session-local. An active parent workflow stays parent-owned; do not publish concurrently from parent and child. A foreign or stale run identifier (ID) is a blocker, not permission to start another workflow automatically. If the tool says that this session's run ended at ordinary settlement, a fresh entry within the original still-authorized scope is permitted. This includes publication after an incomplete `/pr` run if the original instruction already permits that work; no new approval is needed. The full lifecycle still requires `/pr`. Follow its recovery checks. A failed or cancelled run needs result and journal inspection first. Never replay an uncertain action or delete recovery records. 1. Read repository instructions and inspect local status and changes. A create/update request permits only intended work. Never include secrets, `.context/`, or unrelated changes. Stop if ownership is unclear. Preserve coherent staging; the helpers commit whole paths and reject partial staging. Do not stash, discard, or hide other work. 2. Keep an explicit user base as the `base` argument. For an existing proven PR, it must equal that PR's base. For creation, it must equal one `branch..gh-merge-base` value or the validated `origin` default branch. A mismatch stops before publication. Do not retarget a PR or silently write Git configuration. If the user wants another creation base, ask for permission to set the branch's repository-local `gh-merge-base`, then start again. Never change global configuration or infer the base from the branch name. 3. An absent configured push target can require repository-local upstream configuration. Ask for this specific permission unless the user already gave it for this repository and branch. Set `allowUpstream: true` only with that permission. Omit it otherwise; the helper stops before linking or inferred-target creation. This permission does not permit other configuration changes. 4. Call `pi_git_pr` with the explicit `base`, if supplied, and `allowUpstream` as above. Do not push with shell tools, run `gh pr create`, edit PR metadata, or call a route helper without its reserved run ID. Do not start another entry while a run is active. Ambiguous destinations, PRs, and published branches without a proven PR remain blockers. 5. If the result has `handoff`, end this turn. The reserved package skill enters this same session at settlement with its exact `runId` and initial action. Follow it through inspection, scoped commits, relevant non-destructive checks, and publication. Do not guess a run ID or use `sendUserMessage` to imitate a command. Local sync may fast-forward or rebase onto the PR head; it never rebases onto the base under this authorization. 6. Existing PRs are reused by validated repository, destination ref, and exact head, without automatic title/body changes. Creation chooses a concise Conventional Commit title and a body with `Summary` and `Testing`. Exact-OID pushes, saved leases, authority checks, and uncertain-outcome recovery belong to the package helpers. After an uncertain mutation, stop and inspect its outcome; never replay it. 7. Report the validated PR URL and any blocker. For a direct worker, keep the required JSON completion object and put the URL in its `answer`; do not replace that object with a plain URL. If the PR needs feedback, CI repair, a base update, or merge, report that creation/publication stopped there. Do not claim that these steps ran. The user must invoke `/pr` to authorize the full lifecycle. An explicit base-update order needs only the separate `update-branch` scope.