Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

pr-open

Estrellas3

Forks0

Actualizado9 de marzo de 2026 a las 02:03

Prepare and open a GitHub pull request with the GitHub CLI. Use when the user asks to open a PR, create a pull request from the current branch, draft a PR title and body, compare against a base branch, or submit a PR with `gh pr create`.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

morgsmccauley

morgsmccauley/dotfiles

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

Explorador de archivos

2 archivos

SKILL.md

readonly

name	pr-open
description	Prepare and open a GitHub pull request with the GitHub CLI. Use when the user asks to open a PR, create a pull request from the current branch, draft a PR title and body, compare against a base branch, or submit a PR with `gh pr create`.

Gh Pr Open

Inspect branch state before drafting the PR.

Determine the base branch from user input when provided; otherwise default to main.
Check the current branch name before opening a PR.
Inspect the branch diff and commit list against the base branch so the title and body match the actual changes.

Prepare the branch if needed.

If the working tree has uncommitted changes, use the git-commit skill first so the PR is opened from committed work.
If the current branch is the base branch, create a new branch with a sensible name before opening the PR.
If HEAD is detached, treat that as a normal workflow, especially when detached at origin/main. Create a new branch from the current commit before opening the PR.
Push the branch if it is not yet on the remote.
Prefer non-interactive git and gh commands.

Draft the PR before submission.

Use the conversation context, commit list, and diff to draft the title and description.
Format the PR title as a conventional commit and include the service or package name as the scope when it is identifiable from the changed files or repository context, for example feat(sender): add retry guard.
Treat extra invocation tokens as modifiers when they are unambiguous. If the user invokes $pr-open non_prod, suffix the PR title with (non_prod).
Do not pause for title/body approval unless the user explicitly asks to review the copy first.
Keep the title concise and specific.

Use this PR body structure unless the repository already has a stronger convention:

# Summary
[Briefly describe the overall changes]

# Changes
- [Concrete change]
- [Concrete change]

Submit and open the PR.

Run gh pr create against the chosen base branch.
If the user invoked $pr-open non_prod, run gh pr merge --auto --squash <pr-url-or-number> after creating the PR.
Return the PR URL in the final response.

Más de este repositorio

mismo repositorio

datadog-metrics

morgsmccauley/dotfiles

Access Datadog metrics in the us5 site with environment-provided credentials and the helper script. Use when Codex needs to discover active metric names, query timeseries data, inspect metric tags, or answer monitoring questions from Datadog metrics.

2026-03-303

codebase-walkthrough

morgsmccauley/dotfiles

Understand and explain an unfamiliar repository by inspecting its structure, entrypoints, runtime flows, and key modules. Use when the user asks for onboarding to a new codebase, wants an architecture walkthrough, asks where to start reading, needs a feature traced end-to-end, or wants a concise explanation of how folders, services, APIs, jobs, data models, or tests fit together.

2026-03-093

git-commit

morgsmccauley/dotfiles

Create a focused git commit from the current working tree using conventional commits. Use when the user asks to commit changes, write a commit message, choose a commit type like feat or fix, stage the right files, or turn a finished edit into a clean commit without scooping up unrelated work.

2026-03-083

Gh Pr Open

Inspect branch state before drafting the PR.

Determine the base branch from user input when provided; otherwise default to main.

Check the current branch name before opening a PR.

Inspect the branch diff and commit list against the base branch so the title and body match the actual changes.

Prepare the branch if needed.

If the working tree has uncommitted changes, use the git-commit skill first so the PR is opened from committed work.

If the current branch is the base branch, create a new branch with a sensible name before opening the PR.

If HEAD is detached, treat that as a normal workflow, especially when detached at origin/main. Create a new branch from the current commit before opening the PR.

Push the branch if it is not yet on the remote.

Prefer non-interactive git and gh commands.

Draft the PR before submission.

Use the conversation context, commit list, and diff to draft the title and description.

Format the PR title as a conventional commit and include the service or package name as the scope when it is identifiable from the changed files or repository context, for example feat(sender): add retry guard.

Treat extra invocation tokens as modifiers when they are unambiguous. If the user invokes $pr-open non_prod, suffix the PR title with (non_prod).

Do not pause for title/body approval unless the user explicitly asks to review the copy first.

Keep the title concise and specific.

Use this PR body structure unless the repository already has a stronger convention:

# Summary [Briefly describe the overall changes] # Changes - [Concrete change] - [Concrete change]

Submit and open the PR.

Run gh pr create against the chosen base branch.

If the user invoked $pr-open non_prod, run gh pr merge --auto --squash <pr-url-or-number> after creating the PR.

Return the PR URL in the final response.