Menu
Use when creating a new GitHub pull request, opening a PR for the current branch, or when another skill (like ship-it) needs a PR created for a branch that does not have one yet.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | create-pr |
| description | Use when creating a new GitHub pull request, opening a PR for the current branch, or when another skill (like ship-it) needs a PR created for a branch that does not have one yet. |
Open a new GitHub pull request for the current branch using the repo's PR template if one exists. Defaults to --draft.
git rev-parse --abbrev-ref --symbolic-full-name @{u} fails, run git push -u origin HEAD first.gh pr view --json number 2>/dev/null returns 0. In that case the caller likely wants gh pr edit instead.Check for a template in this order and use the first match:
.github/pull_request_template.md.github/PULL_REQUEST_TEMPLATE.mddocs/pull_request_template.mdpull_request_template.md (repo root).github/PULL_REQUEST_TEMPLATE/*.md. If multiple, prefer one matching the dominant commit type (feature.md or feat-* for feat: commits, bugfix.md for fix:, etc.). If still ambiguous, ask the user which to use.Filename matching is case-insensitive on macOS but case-sensitive on Linux; check both common cases.
If none found, use the standard body in step 4.
Use Conventional Commits format derived from the branch's commits (git log <base>..HEAD):
Apply terse-output to the body: bullets over prose, no filler ("just", "really"), no hedge openers ("I noticed that…", "You might want to consider…"). Lead with what changed and why; skip implementation play-by-play.
With template: read the template file and fill its sections from the diff (git diff <base>...HEAD) and commit history. Preserve the template's structure, headings, comments, and checklists exactly. Leave checklist items unchecked unless the work demonstrably satisfies them. For sections that do not apply, mark them N/A only if the template requires a value; otherwise leave the section body empty.
Do not strip HTML comments from the template (they are often instructions to the PR author and may be intentionally rendered as hidden guidance).
Without template, use this body:
## Summary
<1–3 bullets covering what changed and why>
## Test plan
- [ ] <specific verification steps>
Per no-post-without-confirmation, present the title and body to the user and wait for explicit approval before creating.
After approval, write the body to a temp file (avoids shell-escaping issues with multiline markdown) and create the PR:
gh pr create --draft --title "<title>" --body-file /tmp/pr-body.md
Always pass --draft per draft-prs. Only omit --draft if the user explicitly asked for a ready/non-draft PR.
Print the resulting PR URL.
Use when asked to rewrite or format text in the user's voice, "make this sound like me", "match my voice", "de-stiffen this", when text "reads too corporate / businessy / stiff", to "strip the em-dashes / agent typography", or to draft a Slack announcement, PR body, or doc in the user's voice. Also /match-voice.
Use when writing or rewriting reader-facing technical text — documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports, API guides, agent/system prompts — or when asked to "de-slop", "make this readable", "simplify this doc", "write for non-native readers", "apply STE", "Simplified Technical English", or "ASD-STE100", or to prepare text for translation. Also use to CHECK such text for clarity violations. Do NOT use for chat replies, PR/review comments, or commit messages (that is terse-output), nor for marketing, brand, or personal-voice writing (that is match-voice) — this skill deletes persuasion by design.
Use when the user asks for a deep review, full review, comprehensive review, production readiness assessment, full audit, multi-domain audit, "security and reliability and code review", or "review everything". Also use when the user explicitly requests performance review alongside the comprehensive request (e.g. "include perf", "review including performance", "deep review with perf"); without that explicit phrasing, performance is excluded. Do NOT use for narrow single-domain reviews (use the matching review-* skill directly).
Review code architecture (SOLID, design patterns, package design, coupling, testability), Go best practices, and protobuf/API design using manual analysis and static analysis tools (gocyclo, staticcheck, buf). Use when the user asks for a code review, architecture review, Go review, protobuf review, SOLID review, or design pattern review.
Use when the user wants to execute an approved implementation plan and says any of "do it" (with a plan in scope), "lets do it" / "let's do it", "confirmed" (as approval to proceed on a plan), "implement the plan", "implement this", "execute the plan", "start implementing", "work through the plan", "implement the next phase", "build it out", "knock out the plan", or "/implement-plan PATH". Also use when a plan file (`./.plans/PLAN.md`, any `./.plans/*.md`, or legacy `./PLAN.md` / `./docs/plans/*.md`) is present and the user signals readiness to begin coding. Do NOT use when the user is still discussing, refining, or asking questions about the plan, nor when no plan exists — short imperatives like "do it" or "confirmed" alone are ambiguous; verify a plan is in scope before activating.
Use when the user asks to review the plan, sanity-check the plan, vet the plan, evaluate the plan, "is this plan ready", feasibility check on a plan, "review-plan PATH", or when another skill (like implement-plan) requests pre-flight plan evaluation before execution. Do NOT use when no plan file is in scope (the user is likely asking for a summary — use Read instead), nor when the user is asking about source code (use review-code), nor when the user wants documentation review (use review-documentation).