| 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 |
To PR
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:
- A PR URL → review branch. Read the PR, write the recommended draft, print it. Leave the PR untouched unless the user asks you to apply it.
- Anything else (including nothing) → create branch. Open a new PR.
Resolving base and head
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.
Create branch
-
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.
Review branch
- Read the PR —
gh pr view <url> --json title,body,headRefName,baseRefName,commits plus gh pr diff <url>.
- Write the draft the same way as the create branch, including the house-style check.
- Print it and say plainly that the PR has not been changed. Offer
gh pr edit as the next step; run it only if the user asks.
Draft format
<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:
- Configurando o ambiente — derive it from the diff, not from memory: a new key in
.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.
- Como testar — the reader is an analista de qualidade: they know the product, not the codebase. Name screens, buttons and menus the way the product names them; give real input values instead of "dados válidos"; cover the error and edge paths the diff introduces, not only the happy one. Write it whenever the diff changes anything a person can reach — a UI, an endpoint, a CLI, a job, an error path. When the change is reachable only by the test suite (refactors, build config, dependency bumps), replace both this section and the one above with the command that proves it, named in Resumo.
- Preparando para o deploy — migrations to run, env vars and secrets to register in the production environment, feature flags to flip, backfills, cache or queue restarts, deploy order against a dependent service, and how to roll back if it goes wrong. Omit it when merging is genuinely the whole deploy.
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".
