Prepare and publish a reviewable pull request
OpenCode v1: Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native skill tool. Slash commands are direct user entry points only.
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-request-23description: 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---5# Prepare and publish a reviewable pull request67> **OpenCode v1:** Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native `skill` tool. Slash commands are direct user entry points only.89Do not create or modify a pull request until the user has explicitly authorized10that external action. A request to implement, verify, or review a change is not11itself authorization to publish it.1213## Establish the delivery boundary14151. Resolve the repository, current branch, base branch, remote, and existing PR16 from current Git state. Never hardcode an owner, repository, or branch.172. Read the complete task-scoped diff, including staged, unstaged, committed,18 and untracked content. Stop if unrelated work cannot be separated safely.193. Read the repository's pull-request template and contribution instructions20 when present. Follow existing title, issue-linking, language, reviewer, and21 merge conventions rather than inventing replacements. Preserve the22 template's headings, order, and checklist; fill its sections instead of23 replacing them with a custom structure.244. Confirm that acceptance criteria are covered and that required gates were25 run after the final diff change. Record exact commands, relevant output, and26 exit codes. Label missing or environment-only proof honestly.2728## Draft before publishing2930Prepare a concise title and body containing:3132- the observable outcome and why it matters;33- the material changes and deliberate non-goals;34- issue or task links using the repository's established closing semantics;35- fresh verification evidence;36- risk, rollout or rollback notes, and focused reviewer guidance;37- any accepted concern, waived review, or unverified behavior required by38 repository policy.3940Avoid implementation diaries, generated filler, copied secrets or personal41data, and claims that exceed the supplied evidence. Present the complete draft42and target base/head to the user when authorization is not already explicit.43If push or PR creation is blocked, keep the local commit intact and return the44exact blocked operation together with the complete template-conforming draft;45never claim that the branch or pull request was published.4647## Create or update4849Use the available GitHub integration or authenticated CLI for the resolved50repository. Update an existing pull request for the branch rather than opening51a duplicate. Perform only the authorized operations; do not merge, alter52project state, request reviewers, or change labels unless those actions were53also authorized.5455Read the resulting pull request back and verify its URL, title, base/head,56body, and current check state. Report the link and any remaining gate or review57work without claiming merge readiness beyond repository policy.
navikt