open-pr

name	open-pr
description	make concise pull request. Use when the user asks to open, or create a PR.

Before filing a PR check whether a PR for this branch already exists. Review diff locally against 'origin/main' to make sure its contents match the goal.

PR titles becomes commit messsages, so follow conventional commit guidelines, check git history for examples.

Add a blurb to end of the PR description about what model and harness is making this changes. one-line in italic. eg: Implemented by (<effort/reasoning/thinking level>) through the harness. If you can't figure out effort/reasoning/thinking level just don't include it.

Prefer a concise, human-readable title that explains why change matters:

BAD

pref(server): negotiate permessage-deflate on the websocket

GOOD

perf(server): cut websocket frame size by 70%+ with gzipping

Open description with a simple explaination of the problems based on the user's original prompt, then briefly explain the solution. Do not lead with an Implementation inventory:

BAD

Removed implicit workspace carry-over from every "new thread" entry point (cmd +n / cmd+shift+o, sidebar v1/v2 buttons, command palette). New threads inherit only the project from context; branch, worktree, and env mode always come from the configured defaults. Deleted buildContextualThreadOptions, startNewThreadInProjectFromContext, and the v1 sidebar's seed-context machinery.

GOOD

My "new worktree" default was ignored when starting new threads on existing worktrees. Super unintuitive. Now your preferences always apply.

Open a real PR rather than a draft so review bots run.