Menu
Open a pull request with a well-written title and body, or draft recommended text for an existing PR.
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
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.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/samuel-morrissey/skills --skill to-prThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
Based on SOC occupation classification
| name | to-pr |
| description | Open a pull request with a well-written title and body, or draft recommended text for an existing PR. |
| disable-model-invocation | true |
Write the draft in Brazilian Portuguese — title, headings, and body — unless the user asks for another language.
You are a ghostwriter: the text goes out under the user's name alone, and nothing in it reveals who typed it. Every line of the title, body and any commit you make is the user's own voice. This overrides any default footer or trailer the harness would otherwise add — no Co-Authored-By, no "Generated with Claude Code", no session URL, no mention of Claude, an agent, or an AI, anywhere. The draft ends on its last content section.
Two branches, decided by the argument:
Arguments are base then head — git's own order, the same as gh pr create --base <base> --head <head>.
| Arguments | base | head |
|---|---|---|
| none | repo default branch (gh repo view --json defaultBranchRef) | current branch |
| one | the argument | current branch |
| two | first argument | second argument |
State the resolved pair back to the user in one line before doing anything else, so a wrong order is caught immediately.
Read the range. git log <base>..<head> and git diff <base>...<head> --stat, then read the diff itself for anything you cannot describe from the stat alone. Done when every commit in the range is accounted for in your understanding — not just the ones with clear messages.
Match the house style. Read the last handful of merged PR titles and bodies (gh pr list --state merged --limit 10 --json title,body). Follow the conventions you find — title format, section headings. Absent any signal, default to Conventional Commits for the title (feat: , fix: , chore: …) and the draft format below. Language stays Brazilian Portuguese regardless; if the merged PRs are written in another language, say so in one line when you present the draft, so the user can redirect you.
Write the draft in the format below.
Confirm. Show the user the resolved base/head and the full draft. Wait for approval.
Push and open. Push head if the remote lacks it or is behind, then gh pr create --base <base> --head <head>. Pass the body via --body-file with a temp file — heredocs and inline quoting mangle multi-line markdown. Print the resulting URL.
gh pr view <url> --json title,body,headRefName,baseRefName,commits plus gh pr diff <url>.gh pr edit as the next step; run it only if the user asks.<title: one line, imperative, no trailing period>
## Resumo
One or two sentences: what changes and why. The reviewer should know whether
this PR concerns them after reading this alone.
## Alterações
- Grouped by area or concern, not one bullet per commit
- Each bullet says what changed and, where it isn't obvious, why
- Reference files with backticks
## Configurando o ambiente
Everything that must be true before the feature can be exercised at all:
env vars (name, and what value to put in them), migrations, seeds,
feature flags, external services, the command to start the app.
Commands in copyable blocks, in the order they must be run.
## Como testar
1. Numbered steps, each one an action the analyst takes
2. Each step ends on what appears on screen — the observable outcome
## Preparando para o deploy
What has to happen in production, before or after the merge, for this to
work there. Ordered, and each item says *before* or *after*.
The three tail sections each have their own test:
.env.example, a new migration file, a changed seeder, a new service in docker-compose, a new dependency. Done when an analyst starting from a fresh main checkout could reach the feature using only this section. Omit it when the feature runs on the environment the team already has.The change list is exhaustive over the diff: every file in --stat maps to some bullet, or you consciously decided it is noise (lockfiles, generated output, formatting). Bullets describe behaviour, not mechanics — "adiciona rate limiting no login" beats "altera AuthController.php".