Create Pr

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 unpublished history against the base. Require reviewable commit boundaries as create-commits produces them: no uncommitted changes, each commit one reviewable purpose kept with its tests or fixtures, ordered as a reviewer should read them. When the worktree is uncommitted or the unpublished history blends purposes, hold creation and return the commit restructuring as the required preceding work instead of performing it here. Never rewrite published or shared history, and never force-push without explicit authorization.
3. Hold creation when required creation information or authorization is missing or ambiguous, or when published or shared history cannot meet the reviewable boundaries without being rewritten. State each blocker and the safe non-rewrite path needed to proceed.
4. Write the pull request body as one short statement of the pull request's purpose and nothing more. When the repository has .github/PULL_REQUEST_TEMPLATE.md, place that statement under the template's structure without expanding it to fill the remaining sections. Add design decisions, background, alternatives, or reading order only after a reviewer or the user asks for that explanation, appending the requested detail to the existing body.
5. Locate any pull request associated with the current branch and carry out the authorized creation or update rather than stopping at its description; record the operation as submitted separately from any result verified by the returned or observed state, 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. Read ~/.claude/skills-config/release-labels.md and select one label per group it defines — the productivity group from the nature of the change, the AI-contribution group from the session's actual share of authorship, the release-level group from impact on the configured core features, inferred from the target repository's CLAUDE.md or README opening when that list is empty — and the milestone it names. Apply only labels and a milestone verified to exist in the target repository; when the config file, a group, a matching label, or the milestone is missing, skip that item, continue the pull request operation, and record the skip with its reason. On creation set all selected items; on update fill only absent labels and an absent milestone, keeping existing ones unchanged unless their change is explicitly requested.
8. 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.
9. Before push or creation, verify the commit order and each commit's diff against the boundaries required in step 2; 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.
10. 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.
11. Report the verified commit boundaries, submitted operations, supported final state, applied changes, failures with reasons, and unresolved outcomes.