oncokb-make-pull-request

The full skill.

Original instructions from the publisher’s SKILL.md

## Scope

- Use for pull request work only: drafting, creating, updating, and validating PR metadata.
- Prefer `gh` CLI for all GitHub PR operations.
- Preserve repository conventions for title format, labels, reviewers, milestones, and linked issues.
- Use `oncokb-github-issues` to create or find a related issue when one does not already exist.
- Do not merge PRs unless the user explicitly asks.

## Core policy

- Collect required PR content from the user; do not assume missing details.
- You may recommend defaults, but wait for user confirmation before using recommended values.
- Users may decline non-blocking recommendations; do not force adoption when policy requirements are still met.
- When a user declines a recommendation, require a short rationale and record it in at least one place: an inline code comment on impacted code, a PR review comment on impacted lines, or the PR summary/body.
- If information is missing, ask one grouped question covering all missing inputs.
- Require at least one user-confirmed PR tag (label) when creating a PR.
- Require at least one related issue link or ID for every PR.
- If no related issue exists yet, invoke `oncokb-github-issues` to create one before creating or updating the PR.
- If multiple remotes exist (`upstream`, `origin`, or others), ask the user which remote to use before any push.
- Never push to `master`, `main`, or any `rc` branch; require the user to perform those pushes themselves.

## Workflow

1. Confirm target and readiness.
   - Identify the repository, current branch, and target base branch.
   - Check working tree status before PR creation.
   - If there are uncommitted changes, ask whether to include them before proceeding.
   - Inspect git remotes; if `upstream`, `origin`, or other remotes exist, ask the user which remote to use for push.
   - If no upstream branch exists and push is needed, push with upstream tracking only after the user confirms remote and target branch.
   - If the target push branch is `master`, `main`, or matches `rc*`, stop and ask the user to do that push manually.
   - Confirm PR kind (`feature`, `fix`, `documentation`, `chore`) with the user.
   - Completion criterion: source branch, base branch, and commit range are explicit and ready.

2. Ensure related issue exists.
   - Ask for related issue link(s)/ID(s).
   - If none exist, invoke `oncokb-github-issues` to create an issue first.
   - After issue creation, confirm whether PR should use `Fixes #...` or `Refs #...` linkage.
   - Completion criterion: at least one related issue URL/ID is confirmed for PR body use.

3. Build accurate PR context.
   - Review commit history and diff versus base branch.
    - Ask the user to provide: what changed, why it changed, and user-visible impact.
    - Ask for risk areas, migration notes, and rollout notes if applicable.
    - Ask whether any agent suggestions were intentionally declined and collect the rationale plus where it should be documented.
    - You may propose draft phrasing based on diff context, but require user confirmation before finalizing PR body text.
    - Completion criterion: PR title/body content can be written from verified branch changes.

4. Draft title and body.
   - Write a specific, searchable PR title aligned with repository style using user-provided details.
   - Use the template that matches the confirmed PR kind.
    - Include only user-provided facts in summary, rationale, testing, and follow-ups.
    - If the user declined non-blocking suggestions, include the rationale in the agreed location (code comment, PR line comment, or PR summary/body).
    - Include a related issue link using user-provided references (`Fixes #123` style when closure is intended, otherwise `Refs #123`).
    - Completion criterion: a reviewer can understand intent, scope, and verification steps without opening local diffs.

5. Create or update PR via `gh`.
   - Create with `gh pr create` when no PR exists.
   - Update existing PR with `gh pr edit` when the branch already has one.
   - For new PRs, fetch repository labels and ask the user to choose at least one tag.
   - In `oncokb/oncokb-skills`, recommend tags from the supported set below and let the user confirm the final selection.
   - Apply requested metadata (reviewers, assignees, labels, milestone, draft/ready state).
   - Completion criterion: PR is present on GitHub with correct metadata, body, and at least one related issue reference.

6. Validate and report.
   - Confirm PR URL, state (draft/ready), base/head branches, and linked issues.
   - Report any failed checks, missing permissions, or metadata that could not be applied.
   - Completion criterion: user has PR URL plus a clear status and next actions.

## Required prompt

Before creating or updating a PR, ask one grouped question for any missing inputs:

- PR kind: `feature`, `fix`, `documentation`, or `chore`
- PR title
- PR body facts (problem, approach, scope, risks, rollout)
- Any declined non-blocking suggestions, including rationale and where to document them (code comment, PR line comment, or PR summary/body)
- Testing performed and exact commands/results to report
- Related issue links/IDs to reference (or permission to create one via `oncokb-github-issues`)
- Metadata to apply: reviewers, assignees, labels (at least one required for new PRs), milestone, draft/ready state

If related issue links/IDs are missing, pause PR creation/update and invoke `oncokb-github-issues` to create one before proceeding.

## PR templates

Use the matching template for the PR kind confirmed by the user.

### Feature

- Title: `Feature: <concise capability>`
- Body sections:
  - Summary
  - Problem or opportunity
  - Implementation approach
  - Testing
  - Risk / Rollout
  - Related issues

### Fix

- Title: `Fix: <concise defect>`
- Body sections:
  - Summary
  - Problem
  - Root cause
  - Fix approach
  - Testing (including reproduction coverage)
  - Risk / Rollout
  - Related issues

### Documentation

- Title: `Docs: <topic updated>`
- Body sections:
  - Summary
  - Documentation gap
  - What changed
  - Validation (render/build/link checks)
  - Audience impact
  - Related issues

### Chore

- Title: `Chore: <maintenance task>`
- Body sections:
  - Summary
  - Maintenance context
  - Scope
  - Validation
  - Risk / Rollout
  - Related issues

## Supported tags for `oncokb/oncokb-skills`

When the repository is `oncokb/oncokb-skills`, use these tags as the recommended choices and ask the user to pick one or more:

- `major` (major changes)
- `feature` (new features)
- `enhancement` (enhancements)
- `fix`, `bugfix`, `bug` (bug fixes)
- `performance` (performance tweaks)
- `style tweak` (style tweaks)
- `documentation` (documentation)
- `cleanup` (cleanup)
- `devops` (testing, configuration, deployment)
- `chore`, `dependencies` (maintenance)

If a user requests a tag outside this set, check whether the label exists in the repository and confirm before applying it.

## Quality bar

- Never invent test results; only report commands actually run and their outcomes.
- Keep titles and bodies concrete; avoid placeholders and vague summaries.
- Ensure every non-trivial commit in the branch is represented in PR context.
- If the user declines a non-blocking recommendation, preserve that choice and document the rationale in code comments, PR line comments, or PR summary/body as requested.
- Do not create a PR without at least one confirmed tag (label).
- Do not create or update a PR without at least one related issue link or issue ID in the PR body.
- When missing, create the issue through `oncokb-github-issues` rather than continuing without issue linkage.
- If multiple remotes exist, always get explicit user remote selection before pushing.
- Never push to `master`, `main`, or `rc*`; require the user to run those pushes themselves.
- Flag blockers early: no push permission, missing reviewers, branch protections, or missing repo access.