create-stigmer-oss-pull-request

Create a Stigmer OSS pull request

Two modes, one procedure. Asked for the title and body only, produce the two blocks below and change nothing. Asked to open the PR, produce them, push, and run gh pr create from the worktree, non-interactively; if a prerequisite is missing (gh not installed or not authenticated), stop with the command that fixes it.

Preconditions

• The branch already exists: work happens in a git worktree that owns it, so there is no branch to create here. Commits come from .agents/skills/commit-stigmer-oss-changes/SKILL.md; uncommitted changes are committed there first or left out deliberately.
• gh auth status succeeds and origin is writable.
• Base branch: gh repo view --json defaultBranchRef -q .defaultBranchRef.name, falling back to main.
• One pull request per branch. If gh pr list --head <branch> finds one, push and stop; never open a second.
• The change was written and verified under .agents/skills/test-gate/SKILL.md; load it now if it is not already loaded, and answer its questions before "done" before writing the test plan.

Read the branch before writing

git log --oneline origin/main..HEAD
git diff --name-status origin/main...HEAD
git diff --stat origin/main...HEAD

The commits say what changed and why; the file list decides the scope.

The title

One line, in a fenced text block when drafting:

<type>(<scope>): <imperative summary>

<type> is one of feat, fix, refactor, docs, test, perf, ci, build, chore, revert; <scope> follows the scope rule in the commit skill (the most affected area from the repository map, path-like, repo for repository-wide changes); the summary is imperative, specific, at most 72 characters after the prefix, no trailing period.

The body

A fenced markdown block when drafting. Use the sections that apply and omit the rest:

## Summary

<one to three sentences in plain language>

## Context

<the problem, bug or goal that made the change necessary>

## Changes

- <key change, grouped by area when several>

## Implementation notes

- <a decision or trade-off a reviewer should know>

## Breaking changes

- <what breaks and how to migrate, or "None">

## Test plan

- <the checks that ran, with their summary lines; manual steps; screenshots>

## Risks

- <what could go wrong and how to roll back>

Closes #<issue>

The test plan quotes evidence, not intentions: the summary line of each check that ran, as the root guide's verification map asks. A PR that fixes an issue carries Closes #N in the body, where it survives a squash merge.

No body promises a check to be read after the next release. A clause is proven by a test, or dropped. What only a released build can show becomes one of the release's own checks, added by this PR to the release workflow that publishes the thing (.agents/skills/release-stigmer-oss/SKILL.md names each), so every release reads it again.

Nothing merges into main but through the checks its ruleset requires: Gate and Test integrity on the pull request, and, while the ruleset says so, Review verdict and a merge queue that runs Gate and Test integrity again on the queue's commit. When a review is needed, and what a verdict is, is in .agents/skills/review-pull-request/SKILL.md ("When a review is needed"); a verdict is a comment, never a section of this body. The merge arms gh pr merge <n> --auto (with --squash when the brief's ruleset read gives queue: false) and hands back; nobody waits. The local checks the test plan quotes still come first, because a red Gate costs a round trip.

Opening it

git push -u origin "$(git branch --show-current)"
gh pr create --title "$TITLE" --body "$BODY" [--draft] [--reviewer ...] [--label ...]

One PR per milestone, opened once the milestone is built and verified locally. Before that the branch is pushed with no PR, which runs no CI, and a fix found while building rides the milestone's PR unless another change needs it on main now. A PR per project would hold its work off main for days, drift against every other merge, and expose more lanes to each flaky test in the queue. Open a draft only when the owner asks to see the work early; a draft is reviewed when it is marked ready. Once the pull request is open and its local checks pass, run .agents/skills/review-pull-request/SKILL.md when its "When a review is needed" section says to, and act on the verdict as it says. Report the PR URL and any verdict. Merging is a separate, explicitly requested act, never part of opening.