Determine base branch
- Treat slash-command arguments as freeform PR drafting guidance, not positional parameters.
- Use a base override only when the prompt explicitly frames it as the base branch, for example base branch is <branch> or use <branch> as the base.
- Otherwise resolve the default branch locally in this order:
  - git symbolic-ref refs/remotes/origin/HEAD
  - git rev-parse --verify refs/remotes/origin/main
  - git rev-parse --verify refs/remotes/origin/master
  - git rev-parse --verify main
  - git rev-parse --verify master
- Prefer the remote-tracking ref when available; otherwise use the local branch name.
- If invalid, stop: Invalid base branch: <name>.
Find PR template
- Check the repo for a PR template using file tools (glob/read):
  - .github/pull_request_template.md
  - .github/PULL_REQUEST_TEMPLATE.md
  - .github/PULL_REQUEST_TEMPLATE/*.md
  - .github/pull_request_template/*.md
- If no local template, use the GitHub MCP to check the repo for one.
- If no template exists, use a default: ## Summary, ## Testing, ## Risks.
Analyze branch changes
- Assume the branch is already committed and pushed unless the user asks for help with that.
- Use git's own flags to limit output; never pipe to head/tail (pipes break permission matching).
- Prefer a practical summary of current branch work over exhaustive commit archaeology.
- Use 30 commits for log context unless the prompt explicitly asks for a different count.
```
git branch --show-current
git diff --stat <base>...HEAD
git diff <base>...HEAD
git log --oneline -<N> HEAD
```
- If context is large, summarize by file-level impact and recent intent.
Draft PR
- Extract the main intent and user-visible impact.
- Fill template sections with concrete, repo-relevant details.
- Keep content concise and specific.
- Do not invent tests or behavior that didn't happen.
- Do not include a commit-by-commit changelog.
- If a template section doesn't apply, write N/A.
- Preserve template heading names and order.
Construct command
- Build a gh pr create command using shell-safe quoting.
- For multiline bodies, prefer --body-file - <<'EOF' to avoid brittle inline escaping.
```
gh pr create --base "$BASE" --title "$TITLE" --body-file - <<'EOF'
<body>
EOF
```
- Set BASE and TITLE with shell-safe quoting when they contain spaces or special characters.
- Choose a heredoc delimiter that does not appear as a standalone line in the body.
Present and confirm
- Show: Title:, Body:, the exact command, then Run this command?
- Treat execution as permission-gated. Only execute if the user explicitly asks to create/open the PR in the current turn.
- If approved, execute.
- If edits requested, revise and re-confirm.

Rules

Do not write the PR body to a file; build it inline.
Use shell-safe quoting throughout.
Do not include preamble text or follow-up questions beyond the confirmation.
Do not fetch, push, or re-verify branch state unless the user asks or the workflow is blocked without it.
In draft/proposal mode, never run mutating GitHub commands. Specifically forbidden until explicit user authorization: gh pr create, gh pr edit, gh pr merge, gh pr close, and any equivalent GitHub write action.

Más de este repositorio

mismo repositorio

agent-docs

stevvooe/dotfiles

Write documentation consumed by LLM agents — AGENTS.md, skill files, .ai/ plans, and agent instructions

2026-04-213

human-docs

stevvooe/dotfiles

Write documentation for human readers — READMEs, design docs, protocol specs, ADRs, runbooks, and API guides

2026-04-033

grafana-dashboard

stevvooe/dotfiles

Iterate on Grafana dashboard JSON files. Use when the user wants to create, modify, or fix Grafana dashboards — including panel layout, queries, colors, variables, and styling.

2026-03-203

opencode-db-inspect

stevvooe/dotfiles

Inspect local OpenCode session data safely with the `opencode db` command

2026-03-203

design-doc-workflow

stevvooe/dotfiles

Keep DESIGN.md and plan docs synchronized with implementation decisions across repositories

2026-03-133

distributed-systems

stevvooe/dotfiles

Apply a rigorous distributed-systems lens for design, debugging, and implementation

2026-03-133

name	github-pr
description	Draft and create pull requests using the repository's conventions and template

Workflow

Determine base branch
- Treat slash-command arguments as freeform PR drafting guidance, not positional parameters.
- Use a base override only when the prompt explicitly frames it as the base branch, for example base branch is <branch> or use <branch> as the base.
- Otherwise resolve the default branch locally in this order:
  - git symbolic-ref refs/remotes/origin/HEAD
  - git rev-parse --verify refs/remotes/origin/main
  - git rev-parse --verify refs/remotes/origin/master
  - git rev-parse --verify main
  - git rev-parse --verify master
- Prefer the remote-tracking ref when available; otherwise use the local branch name.
- If invalid, stop: Invalid base branch: <name>.
Find PR template
- Check the repo for a PR template using file tools (glob/read):
  - .github/pull_request_template.md
  - .github/PULL_REQUEST_TEMPLATE.md
  - .github/PULL_REQUEST_TEMPLATE/*.md
  - .github/pull_request_template/*.md
- If no local template, use the GitHub MCP to check the repo for one.
- If no template exists, use a default: ## Summary, ## Testing, ## Risks.
Analyze branch changes
- Assume the branch is already committed and pushed unless the user asks for help with that.
- Use git's own flags to limit output; never pipe to head/tail (pipes break permission matching).
- Prefer a practical summary of current branch work over exhaustive commit archaeology.
- Use 30 commits for log context unless the prompt explicitly asks for a different count.
```
git branch --show-current
git diff --stat <base>...HEAD
git diff <base>...HEAD
git log --oneline -<N> HEAD
```
- If context is large, summarize by file-level impact and recent intent.
Draft PR
- Extract the main intent and user-visible impact.
- Fill template sections with concrete, repo-relevant details.
- Keep content concise and specific.
- Do not invent tests or behavior that didn't happen.
- Do not include a commit-by-commit changelog.
- If a template section doesn't apply, write N/A.
- Preserve template heading names and order.
Construct command
- Build a gh pr create command using shell-safe quoting.
- For multiline bodies, prefer --body-file - <<'EOF' to avoid brittle inline escaping.
```
gh pr create --base "$BASE" --title "$TITLE" --body-file - <<'EOF'
<body>
EOF
```
- Set BASE and TITLE with shell-safe quoting when they contain spaces or special characters.
- Choose a heredoc delimiter that does not appear as a standalone line in the body.
Present and confirm
- Show: Title:, Body:, the exact command, then Run this command?
- Treat execution as permission-gated. Only execute if the user explicitly asks to create/open the PR in the current turn.
- If approved, execute.
- If edits requested, revise and re-confirm.

Rules

Do not write the PR body to a file; build it inline.
Use shell-safe quoting throughout.
Do not include preamble text or follow-up questions beyond the confirmation.
Do not fetch, push, or re-verify branch state unless the user asks or the workflow is blocked without it.
In draft/proposal mode, never run mutating GitHub commands. Specifically forbidden until explicit user authorization: gh pr create, gh pr edit, gh pr merge, gh pr close, and any equivalent GitHub write action.