pr-create

name

pr-create

description

Audit a prepared MOOSE branch for applicable AGENTS.md instructions, MOOSE contribution standards, tests, documentation, and PR readiness; draft and, only after explicit approval, push the branch and open a draft GitHub pull request against next. Use when someone asks to create, open, prepare, or submit a MOOSE PR. Do not use this to review someone else's PR or to address feedback on an existing PR.

Creating a MOOSE Pull Request

Create a draft PR only after the exact candidate diff passes MOOSE's local instructions and contribution gates. Treat branch preparation and GitHub publication as separate, approval-controlled phases.

Use the pr-review skill for the MOOSE review standard and the codegraph skill for its code-navigation mechanics. Use verify-changes for build and test execution. Do not use the posting step from pr-review.

Step 1 - Establish the candidate

1. Find the repository root, current branch, remotes, upstream tracking state, authenticated GitHub user, and the remote for idaholab/moose.
2. Use that canonical remote's next ref as the integration base. Fetch it if necessary, but do not rebase or merge it into the branch without approval.
3. Inspect git status, the commits in <base>..HEAD, and the complete <base>...HEAD diff. Preserve unrelated working-tree changes.
4. Check whether the branch already has an open PR. If it does, stop and return its URL instead of creating a duplicate.
5. Stop if there is no committed PR diff. If uncommitted changes appear to belong in the PR, propose the exact staging and commit operation rather than performing it silently.

Record the candidate head SHA. Any approved operation that changes the branch invalidates the audit below; restart the audit from the new SHA.

Step 2 - Enforce every applicable AGENTS.md

For each changed path, read only the AGENTS.md files at the repository root and in directories between the repository root and the changed path. Never search above the repository root. Apply all non-conflicting instructions; when instructions conflict, the closest file to the changed path takes precedence.

Build a concise compliance table containing the instruction, affected paths, evidence, and pass/block result. A violation is a blocker: show the exact location and propose the smallest repair, but do not repair it without user approval.

Audit removed comments explicitly

Inspect deleted comment lines throughout the diff, not merely comments next to changed code. For every removed preexisting comment, establish one of these:

• The code it documented was removed.
• The change made the comment incorrect, and the comment was updated rather than silently discarded.
• Its correct meaning was preserved by a justified relocation.

If none applies, treat the removal as a blocking violation and propose restoring the comment. Never accept comment deletion merely because the code seems self-explanatory or the diff becomes shorter.

Step 3 - Run the MOOSE readiness gates

Run Steps 0-4 of pr-review in local-branch mode and stop before its optional posting step. In particular:

• Require CodeGraph as that skill specifies.
• Require at least one commit in <base>..HEAD to reference an issue, then read the referenced issues for intent. Do not require every commit to carry its own issue reference.
• Check design and scope, reuse, the MOOSE Code Standard, tests and SQA metadata, documentation, and new-object stub pages.
• Treat every "required change" as a blocker. Suggestions are not blockers.
• Use verify-changes to verify the changed behavior. A failing relevant check is a blocker.

If the user explicitly declines or cannot provide an environment for relevant verification and verify-changes reports checks as not run, the user may explicitly approve opening a draft with those checks outstanding. Never conceal the missing verification.

Step 4 - Draft the PR

Read the current .github/PULL_REQUEST_TEMPLATE.md instead of relying on a memorized template. Produce:

• A concise title describing the branch's single purpose.
• An issue reference. Use refs #... unless the issue and branch clearly show that merging the PR should close it.
• A one-line footer disclosing that the description was generated by the actual model and interface in use, at the request of the authenticated user. Do not hardcode a model or client name.

Do not duplicate issue content in the PR body. If the linked issue's completed feature/enhancement or bug-report fields already provide the motivation, design or reproduction context, and impact needed to understand the change, omit the PR template's Reason, Design, and Impact sections entirely. If the linked issue is incomplete for the actual change, add only the missing context under the applicable template heading; do not fill all three sections by default.

Do not add reviewers, labels, projects, milestones, or assignees unless the user requests them.

Step 5 - Obtain approval for Git operations

Never stage, commit, amend, rebase, or force-push without explicit user approval. When one is needed:

1. Explain why it is needed.
2. Show the exact files, commit message, source/target branch, and command.
3. Request separate approval for history rewriting.
4. Prefer --force-with-lease to an unrestricted force-push.
5. After the approved operation, restart Steps 1-3 against the new candidate SHA.

Do not bundle branch-preparation approval with approval to push or create the PR. Complete the approved preparation, rerun the full audit, and only then prepare a separate publication preview and request.

Once the audit passes, show one publication preview containing:

• Base and head repositories/branches.
• Title and complete body.
• Test results and explicitly unrun checks.
• Exact normal push and gh pr create commands.

Publishing is externally visible. Obtain explicit approval for the preview before pushing or creating the PR. Do not treat the initial request to "create a PR" as approval of an unseen title, body, or push target.

Step 6 - Publish and verify

After approval:

1. Push normally to the approved fork and branch. Do not force-push unless it was separately approved.
2. Store the approved body in an untracked temporary file outside the repository and run gh pr create with explicit --base next, --head, --title, --body-file, and --draft.
3. Do not use gh pr create --dry-run for preview: it may still push.
4. Never mark the PR ready for review; leave that to the user.
5. Read the created PR back with gh pr view and verify its URL, title, base, head, body, and draft state.

If publication fails, inspect the failure before retrying. Never create a second PR to recover from an ambiguous first attempt.

Finish concisely

After creation, return only a brief success note and the PR URL. Do not repeat the title, body, base/head branches, draft state, tests, or other information the user can inspect on GitHub or already reviewed in the publication preview. Expand the response only for an action that failed, was skipped, remains blocked, or still requires user input. If no PR was created, do not imply otherwise.