pr-open

/octopus:pr-open percorre o diff contra a base branch, escreve um título de PR (um único emoji + formato Conventional Commits) e um corpo (Summary / Related Issues / How to Test / Screenshots) seguindo as convenções de PR do Octopus, e então roda gh pr create. Se a branch não tiver sido enviada, ela é enviada primeiro.

Por que o agente escreve o texto e a CLI faz o push

A divisão é deliberada. O agente tem todo o contexto que faz um bom corpo de PR — o que mudou, o que foi tentado e não deu certo, quais decisões merecem atenção do reviewer. A CLI não tem nada disso; está apenas executando comandos de shell. Combinar os dois em um único script bash que “escreve um corpo de PR” ou produziria saída genérica baseada em template (ruim) ou duplicaria o raciocínio do agente no lado do bash (pior).

Então o comando tem duas metades: escrita do texto no contexto do agente, mecânica em octopus.sh pr-open. O agente nunca invoca shell para o corpo; a CLI nunca tenta resumir um diff.

Formato do título

Um emoji no início, derivado do prefixo da branch (ou, se ambíguo, do tipo de commit dominante na branch):

Tipo	Emoji	Tipo	Emoji
feat	✨	docs	📝
fix	🐛	test	🧪
refactor	♻️	chore	🔧
perf	⚡	style	🎨
ci	🚀	revert	⏪

Em seguida, o formato Conventional Commits: type(scope): description, mantido abaixo de 70 caracteres para não ser truncado na lista de PRs do GitHub.

Template do corpo

## Summary
- <what changed, in 1-3 bullets>

## Related Issues
Closes #<issue>

## How to Test
1. <step>
2. <step>

## Screenshots (if applicable)

O agente preenche o corpo a partir do diff e do contexto da conversa. Se a conversa referenciou uma issue, a linha Related Issues a captura. Se o diff inclui mudanças de UI, o agente sinaliza que screenshots são esperados antes do merge.

Pareamento

O próximo passo após pr-open é /octopus:pr-review — o agente faz self-review do diff do PR contra o checklist de correção/design/legibilidade e então atribui reviewers humanos. pr-comments roda após o feedback chegar; pr-merge roda após a aprovação.

Abrindo um draft

/octopus:pr-open --draft
/octopus:pr-open main --draft

--draft abre o PR como draft em vez de pronto para review — para feedback antecipado do CI, uma leitura arquitetural antes do trabalho estar terminado, ou uma branch stacked. O título e o corpo são escritos exatamente da mesma forma; só o estado do PR muda. A flag é agnóstica de posição: a branch de destino é o primeiro argumento que não é uma flag.

PRs draft em repositórios privados exigem um plano pago do GitHub. Quando o gh recusa, o comando avisa e para — ele não abre silenciosamente um PR normal no lugar do draft que você pediu.

Promova depois com pr-ready.

Fonte: commands/pr-open.md