/pr-create

name: pr-create
description: Generate a PR description and create a GitHub pull request. Invoke when user wants to create a pull request, says "create a PR", "submit a PR", "open a pull request", or uses /pr-create. Creates the PR as soon as the description is ready, with no approval step, then shows the description and URL so CI and preview environments can start testing. Writes terse descriptions and supports ticket numbers.

PR Create

Generate a terse PR description and create a GitHub pull request. The main session runs this skill directly — no orchestrator agent is involved.

⚠️ Side Effect Warning

**This skill creates a GitHub pull request** — a publicly visible, permanent action that:

• Pushes your branch to the remote repository
• Creates a PR visible to all repository members
• Triggers CI/CD pipelines and notifications

**No approval step.** The PR is the fastest route to CI, preview environments, and the test suites that run against them, so this skill creates it as soon as the description is ready and shows the result afterwards. The description can be changed with `gh pr edit` once it exists. Review happens on the PR, not before it.

Usage

• "Create a PR for my current branch"
• "Create a pull request with ticket PROJ-123"
• `/pr-create [ticket-number]`

Prerequisites

• Changes committed to a feature branch (not main/master)
• GitHub CLI (`gh`) installed and authenticated
• Remote repository accessible

Workflow

1. Parse arguments

• Look for a ticket reference (e.g., `PROJ-123`) in the arguments, current branch name, or recent commit messages.
• `--concise` is still accepted for muscle memory, but changes nothing: every description is terse (step 6), and the step 5 checks always run.

2. Verify prerequisites

Run in parallel:

• `git status` — confirm working tree is clean (or staged changes are intended for the PR)
• `git branch --show-current` — confirm we're not on the default branch
• `gh repo view --json defaultBranchRef --jq .defaultBranchRef.name` — the default

branch; never assume `main` (many Kanopi repos use `master`). Without `gh`: `git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'`

• `gh auth status` — confirm GitHub CLI is authenticated
• `git remote -v` — confirm the repo has a remote

If on the default branch, stop and tell the user to switch to a feature branch first.

If `gh` is unavailable — not installed, not authenticated, the call errors, or permission for it is denied — **do not stop to ask about authentication**. A missing `gh` never blocks steps 3–6: switch to the Environment fallback (below) and continue the analysis; only the final creation step becomes a manual command for the user. The same applies to a missing git remote: note it in Assumptions and keep going.

3. Analyze changes

Run in parallel:

• `git log --oneline <base>..HEAD` — full commit history on this branch
• `git diff <base>...HEAD` — full diff
• `git diff --stat <base>...HEAD` — files changed summary

Where `<base>` is typically `main` or `1.x` (whichever the repo uses as the default branch — check with `gh repo view --json defaultBranchRef --jq .defaultBranchRef.name`).

4. Detect CMS context

Scan the diff for platform-specific changes:

**Drupal indicators:**

• Files under `config/sync/` → flag config import needed
• `hook_update_N` definitions in `.module` or `.install` → flag database update
• Changes to services, render arrays, or cache tags → flag cache clear
• New module dependencies in `*.info.yml` or `composer.json`

**WordPress indicators:**

• ACF JSON files in `acf-json/` → flag field re-sync
• `register_post_type`, `register_taxonomy`, or rewrite rule changes → flag permalink flush
• Theme template changes or new plugin activations → flag cache clear / plugin activation
• Block changes (`block.json`, `src/blocks/`) → flag editor cache

**Any platform:**

• New environment variables or secrets read by the code → list them
• Lockfile or manifest changes → flag a dependency install
• Build-config, bundler, or asset-pipeline changes → flag an asset rebuild
• Job, worker, queue, or scheduler definitions → flag a restart
• Flag-gated code paths → name the flag to flip
• Anything the deploy pipeline cannot reach → spell out the manual admin step

Name the exact command wherever the project has one — check its deploy scripts, CI config, and README. Omit Deploy Notes only when the diff needs nothing beyond a routine deploy.

5. Run inline quality checks

Use Read, Grep, and Bash directly — no Task() spawns required:

• **Tests** — Grep for new functions/classes and check if matching tests exist in the project's test directory. Note untested code in the PR description.
• **Security** — Grep the diff for risky patterns: raw SQL concatenation, `eval`, `unserialize`, missing nonce/CSRF checks (WP `wp_verify_nonce`, Drupal Form API), unescaped output (`echo $user_input`, missing `esc_html`/`esc_attr`/`Html::escape`).
• **Accessibility** — If UI/template files changed, Grep for: missing `alt=`, missing `aria-label` on icon buttons, color-only state indicators, missing form labels.
• **Performance** — Look for new database queries inside loops (N+1), missing caching, large asset imports without lazy loading.

Note findings briefly in the PR description's relevant sections. Do **not** block PR creation on findings — surface them so the reviewer can decide.

6. Generate PR description

**Resolve the template explicitly** — the repository first, then the org's `.github` repository — following [`references/template-resolution.md`](references/template-resolution.md). Step 7 passes the body with `--body-file`, which skips `gh`'s own template population, so never rely on `gh` to insert it.

If neither exists, use the template below — Kanopi's org default. Complete every section the resolved template contains; omit one only when it genuinely does not apply.

## Description
Teamwork Ticket(s): [PROJ-12