Workflow

1. Resolve the current repository and branch from available context; for creation, also resolve the base branch, title, and information needed for the body.
2. Before creating a new pull request, inspect the worktree and the complete change set against the base. Author commit boundaries for the reader, not from chronology: define each commit by one reviewable purpose and its dependencies, keep an implementation with its tests or fixtures, separate authorized but independent in-scope changes, exclude unauthorized or out-of-scope changes, and order commits in the order a reviewer should read them. When the current plan records a commit-level change map, use it as the split specification. Use one commit only when neither the plan nor the change itself contains a reviewable split line, and record that reason; cost of splitting alone does not qualify.
3. Make the authorized local history match those boundaries before publishing it. When the worktree is uncommitted or the unpublished history is blended (fixes interleaved across boundaries), synthesize a fresh narrative instead of recovering chronology: soft-reset the unpublished branch to its merge base and rebuild commits by selective staging, splitting files that span boundaries by staging hunk patches cut from git diff output with git apply to the index — never with interactive tools (git add -p / -i are unavailable). Write each commit message to tell the reviewer what to look at in that commit. Before pushing, require the final commit's tree to be bit-identical to the last verified tree (empty git diff <verified-ref>); require each intermediate commit to pass checks only when the repository lands pull requests preserving individual commits (rebase / merge commit) — under squash merge, endpoint identity suffices and the pull request body states the intended reading order. Rebuild existing unpublished commits only when that rewrite is explicitly authorized. Never rewrite published or shared history. Never force-push without explicit authorization, and never use force-push to rewrite published or shared history. Otherwise hold creation and distinguish missing authorization for an unpublished rewrite from published non-reviewable history that cannot be rewritten.
4. Hold creation when required creation information or authorization is missing or ambiguous, or when the inspected history cannot meet the reviewable boundaries without rewriting published or shared commits. State each blocker and the safe non-rewrite path needed to proceed.
5. Locate any pull request associated with the current branch and carry out the authorized creation or update rather than stopping at its description, using any explicitly supplied mock interface, fixed response, or local fixture as the observable task environment; record the operation as submitted separately from any result verified by the supplied evidence, and never infer success from an absent response.
6. Create a new pull request as a draft unless the user explicitly requests a reviewable state, and preserve an existing state unless its change is explicitly requested.
7. Limit updates to the current branch's pull request and the requested fields; keep all other pull requests, merge state, close state, and branches unchanged.
8. Before push or creation, verify the resulting commit order and each commit's diff; verify each pull request operation only from returned or subsequently observed state, including the base branch, title, affected content, and final draft or reviewable state.
9. Pair any observed pull request number with its exact returned URL without reconstructing absent values, and record partial results and permission failures without claiming unsupported changes.
10. Report the verified commit boundaries, submitted operations, supported final state, applied changes, failures with reasons, and unresolved outcomes.