Prepare and publish a reviewable pull request
Do not create or modify a pull request until the user has explicitly authorized
that external action. A request to implement, verify, or review a change is not
itself authorization to publish it.
Establish the delivery boundary
- Resolve the repository, current branch, base branch, remote, and existing PR
from current Git state. Never hardcode an owner, repository, or branch.
- Read the complete task-scoped diff, including staged, unstaged, committed,
and untracked content. Stop if unrelated work cannot be separated safely.
- Read the repository's pull-request template and contribution instructions
when present. Follow existing title, issue-linking, language, reviewer, and
merge conventions rather than inventing replacements. Preserve the
template's headings, order, and checklist; fill its sections instead of
replacing them with a custom structure.
- Confirm that acceptance criteria are covered and that required gates were
run after the final diff change. Record exact commands, relevant output, and
exit codes. Label missing or environment-only proof honestly.
Draft before publishing
Prepare a concise title and body containing:
- the observable outcome and why it matters;
- the material changes and deliberate non-goals;
- issue or task links using the repository's established closing semantics;
- fresh verification evidence;
- risk, rollout or rollback notes, and focused reviewer guidance;
- any accepted concern, waived review, or unverified behavior required by
repository policy.
Avoid implementation diaries, generated filler, copied secrets or personal
data, and claims that exceed the supplied evidence. Present the complete draft
and target base/head to the user when authorization is not already explicit.
If push or PR creation is blocked, keep the local commit intact and return the
exact blocked operation together with the complete template-conforming draft;
never claim that the branch or pull request was published.
Create or update
Use the available GitHub integration or authenticated CLI for the resolved
repository. Update an existing pull request for the branch rather than opening
a duplicate. Perform only the authorized operations; do not merge, alter
project state, request reviewers, or change labels unless those actions were
also authorized.
Read the resulting pull request back and verify its URL, title, base/head,
body, and current check state. Report the link and any remaining gate or review
work without claiming merge readiness beyond repository policy.
1---2name: pull-request3description: Prepare and publish a pull request for a verified, scoped change when the user asks to open or update a PR. Use `review` to assess the diff first; implementing or reviewing work alone does not authorize publication.4---56# Prepare and publish a reviewable pull request78Do not create or modify a pull request until the user has explicitly authorized9that external action. A request to implement, verify, or review a change is not10itself authorization to publish it.1112## Establish the delivery boundary13141. Resolve the repository, current branch, base branch, remote, and existing PR15 from current Git state. Never hardcode an owner, repository, or branch.162. Read the complete task-scoped diff, including staged, unstaged, committed,17 and untracked content. Stop if unrelated work cannot be separated safely.183. Read the repository's pull-request template and contribution instructions19 when present. Follow existing title, issue-linking, language, reviewer, and20 merge conventions rather than inventing replacements. Preserve the21 template's headings, order, and checklist; fill its sections instead of22 replacing them with a custom structure.234. Confirm that acceptance criteria are covered and that required gates were24 run after the final diff change. Record exact commands, relevant output, and25 exit codes. Label missing or environment-only proof honestly.2627## Draft before publishing2829Prepare a concise title and body containing:3031- the observable outcome and why it matters;32- the material changes and deliberate non-goals;33- issue or task links using the repository's established closing semantics;34- fresh verification evidence;35- risk, rollout or rollback notes, and focused reviewer guidance;36- any accepted concern, waived review, or unverified behavior required by37 repository policy.3839Avoid implementation diaries, generated filler, copied secrets or personal40data, and claims that exceed the supplied evidence. Present the complete draft41and target base/head to the user when authorization is not already explicit.42If push or PR creation is blocked, keep the local commit intact and return the43exact blocked operation together with the complete template-conforming draft;44never claim that the branch or pull request was published.4546## Create or update4748Use the available GitHub integration or authenticated CLI for the resolved49repository. Update an existing pull request for the branch rather than opening50a duplicate. Perform only the authorized operations; do not merge, alter51project state, request reviewers, or change labels unless those actions were52also authorized.5354Read the resulting pull request back and verify its URL, title, base/head,55body, and current check state. Report the link and any remaining gate or review56work without claiming merge readiness beyond repository policy.
navikt 