| name | new-pr |
| description | Open the pull request for the current spec, following memex PR conventions — resolves branch/base, pushes if needed, fills the repo PR template, English Conventional-Commit title and body, no AI attribution. Use as the final delivery step of the spec flow, or whenever the user asks to open a PR. |
new-pr — Open the spec's pull request
The single sanctioned way to open a PR in a memex repo (rules.md, Git §5 — PR via Command). Never open a PR any other way.
Announce at start: "Opening the pull request..."
Inputs
$ARGUMENTS (optional): target base branch and/or extra instructions — e.g. "to main", "label bug", "draft". Empty → base defaults to main.
Safety gate — never from main
Check the current branch first:
git branch --show-current
If it is main or master, stop and tell the user to create a feature branch first. Do not proceed.
Resolve consent — read the spec
Find the spec driving this branch: the spec.md whose branch: matches the current branch (else the most recently modified spec under .memex/specs/). Read its frontmatter:
mode: autonomous → you may open the PR now without asking (recorded consent — rules.md, Git §2).mode: reviewed → only open when the user has asked for it. If you reached here mid-flow without that ask, stop and wait.- No matching spec (ad-hoc PR) → proceed only if the user explicitly invoked this skill.
Push the branch if needed
git ls-remote --heads origin "$(git branch --show-current)"
If the branch is not on origin, push it (covered by recorded consent — never push main/master):
git push -u origin "$(git branch --show-current)"
Resolve the PR template
Use the repo's template as the body skeleton:
cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null || cat .github/pull_request_template.md 2>/dev/null
If present, fill its sections (do not drop required checklist items — answer them honestly; for a maintainer dogfood PR that edits .memex//.agents/, annotate rather than silently tick). If absent, print one line — PR template not found; using embedded fallback — and use the Embedded fallback at the bottom of this file.
Title and body
- Title — English, Conventional Commits:
<type>(<scope>): <concise summary>. Types: feat, fix, docs, refactor, chore, test, ci. Derive the scope from the area the diff touches.
- Body — English (constitution: committed artifacts are English). Top: ONE product-level sentence (no filenames, no pipeline mechanics) describing WHAT the PR does, then 2–5 concrete bullets (resource + action). For a spec-driven PR, fill
## Summary with context/decisions and link the spec artifacts as absolute GitHub URLs on the branch:
- design:
design.md, spec: spec.md, tasks: tasks.md.
Record the quality-gate results (what ran, what passed) in the template's test-plan/quality section.
- No AI attribution anywhere — no "Co-Authored-By: Claude", "Generated by …" (rules.md, Git §4).
Create the PR
gh pr create --base <BASE> --title "<TITLE>" --body "<BODY>" --assignee @me
Keep --assignee @me unless $ARGUMENTS says otherwise. Add --draft only if asked. After creation, print the PR URL.
Degradation
- No
gh on PATH, or gh auth status fails → stop and print the exact git push + manual PR-creation steps for the user to finish.
- No GitHub remote (
git remote -v empty or non-GitHub) → stop and explain; do not fabricate a PR.
Embedded fallback (when the repo has no PR template)
<one product-level sentence — what this PR does>
- <concrete change 1>
- <concrete change 2>
## Summary
<context, motivation, key decisions, non-goals, trade-offs>
## Spec
- spec: <github-url>
- plan: <github-url>
- tasks: <github-url>
## Quality gate
<tests/validators run, manual checks, CI output>
