| name | pr |
| description | Commit the current change, push a branch, and open a draft PR. Use when the user wants to open a PR for finished work. |
PR
make check green locally first (skip the wait if no Python changed). If the change alters commands, workflows, or behavior, update the relevant docs/ guide in the same diff.- Branch off the right base — usually
main, but case-dependent (e.g. stack onto an open PR's branch when the work builds on it). Commit your files only, message formatted as the title below plus the Co-Authored-By trailer. History stays linear: rebase, never merge commits.
- Push and
gh pr create --draft with the title, description, and label below.
Title
Conventional Commits: type(scope): description. We squash-merge: the PR title becomes the commit subject on main and feeds the release notes.
- type (validated by
pr-title-lint): feat, fix, docs, refactor, perf, test, chore, ci, build, revert, or research (research PRs use scope blue or red).
- scope (optional, unrestricted): the subsystem touched — e.g.
cli, eval, monitor, protocols, trajectories, sandbox, fleet, environments, viewer, live. Omit for cross-cutting work.
- description: imperative, no trailing period. Append
! after type or scope for a breaking change.
- Never put Linear issue IDs in the title — reference the issue in the description instead.
Description
What and why, kept accurate as the branch changes. Link relevant runs (https://equistamp.linuxarena.ai/runs/<run_id>) and trajectories (https://equistamp.linuxarena.ai/trajectories/<trajectory_id>).
Label
Add the matching label — it groups the release notes: tooling, environment, straj, main-task / side-task, bug, documentation.
Don't force-push, merge, close, or post public comments without the user asking.
