菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Scaffold or audit the memex (vault + AGENTS.md + spec templates + bundled skills) in any repo — an externalized, navigable project memory for agents (Claude Code, Codex, Cursor, OpenCode, etc.). Agent-agnostic. Idempotent — safe to run repeatedly. Use when the user wants to set up, verify, or fix the memex in a project.
Sync an installed memex with upstream — reconcile the scaffolded files against the current upstream memex: auto-apply changes to files you never touched, agent-merge the ones you edited, and never touch living vault content. Use when upstream memex changed scaffolded content (a renamed term, a reworded skill) and you want it pulled in without clobbering local edits.
Sync an installed memex with upstream — reconcile the scaffolded files against the current upstream memex: auto-apply changes to files you never touched, agent-merge the ones you edited, and never touch living vault content. Use when upstream memex changed scaffolded content (a renamed term, a reworded skill) and you want it pulled in without clobbering local edits.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when you have an approved design (design.md) for a multi-step task — produces the fused technical spec.md + tasks.md, before touching code.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
| 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. |
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..."
$ARGUMENTS (optional): target base branch and/or extra instructions — e.g. "to main", "label bug", "draft". Empty → base defaults to 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.
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.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)"
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.
<type>(<scope>): <concise summary>. Types: feat, fix, docs, refactor, chore, test, ci. Derive the scope from the area the diff touches.## Summary with context/decisions and link the spec artifacts as absolute GitHub URLs on the branch:
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.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.
gh on PATH, or gh auth status fails → stop and print the exact git push + manual PR-creation steps for the user to finish.git remote -v empty or non-GitHub) → stop and explain; do not fabricate a PR.<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>