pr-open

/octopus:pr-open walks the diff against the base branch, writes a PR title (single emoji + Conventional Commits format) and a body (Summary / Related Issues / How to Test / Screenshots) following Octopus PR conventions, then runs gh pr create. If the branch isn’t pushed, it’s pushed first.

Why the agent writes the prose and the CLI does the push

The split is deliberate. The agent has all the context that makes a good PR body — what changed, what was tried that didn’t work, which decisions deserve reviewer attention. The CLI has none of that; it’s just running shell commands. Combining them into a single bash script that “writes a PR body” would either produce generic templated output (bad) or duplicate the agent’s reasoning on the bash side (worse).

So the command is two halves: prose-writing in the agent’s context, mechanics in octopus.sh pr-open. The agent never shells out for the body; the CLI never tries to summarise a diff.

Title format

One emoji at the start, derived from the branch prefix (or, if ambiguous, from the dominant commit type on the branch):

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

Then Conventional Commits format: type(scope): description, kept under 70 characters so it doesn’t truncate in GitHub’s PR list.

Body template

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

## Related Issues
Closes #<issue>

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

## Screenshots (if applicable)

The agent fills the body from the diff and the conversation context. If the conversation referenced an issue, the Related Issues line picks it up. If the diff includes UI changes, the agent flags that screenshots are expected before merge.

Pairing

The next step after pr-open is /octopus:pr-review — the agent self-reviews the PR diff against the correctness/design/readability checklist, then assigns human reviewers. pr-comments runs after feedback arrives; pr-merge runs after approval.

Opening a draft

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

--draft opens the PR as a draft instead of ready for review — for early CI feedback, an architectural read before the work is finished, or a stacked branch. The title and body are written exactly the same way; only the PR’s state differs. The flag is positional-agnostic: the target branch is the first argument that isn’t a flag.

Draft PRs on private repositories require a paid GitHub plan. When gh refuses, the command says so and stops — it will not quietly open a regular PR in place of the draft you asked for.

Promote it later with pr-ready.

Source: commands/pr-open.md