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.

Source: commands/pr-open.md