Create PR

Create a PR

Write the title and the description, then run the linter before you post:

python3 .agents/skills/create-pr/lint_pr.py lint \
    --title "fix(libero): reset action queues between episodes" \
    --body-file /tmp/pr-body.md

Exit code 1 means at least one ERROR — fix it and re-run. It is the same checker you point at a PR that is already open:

python3 .agents/skills/create-pr/lint_pr.py lint --pr 1444

The rules come from CONTRIBUTING.md ("PR Title and Description"), .github/PULL_REQUEST_TEMPLATE.md, and — for the title — the required pr-title-check job, which runs openGemini/pr-title-checker with strict: true. Every title rule that job enforces is an ERROR in the linter, so a clean lint means the check passes. Paths below are relative to the repo root.

Why this exists

Over the 25 most recently merged PRs the linter reports errors on 11 of them. The dominant failures, in order: template sections dropped (14), Types of changes / Checklist with nothing ticked (9), template <!--- ... --> hints left in (9), prose above the first heading (5). PR #1421 is the worst case — the whole body was pasted with a two-space indent, which nests every ### heading inside the Description and breaks the results table outright.

1. Gather the facts before writing a word

Never describe the PR from memory of what you intended. Read the diff:

git fetch origin main
git log --oneline origin/main..HEAD
git diff --stat origin/main...HEAD

You need, concretely:

• Which component the diff touches — that becomes the scope.
• Every user-visible change — a new config key, a renamed flag, a moved doc page, a changed default. Internal churn does not go in the description.
• What you actually ran to verify it — the e2e config name, the eval numbers, pre-commit run --all-files. "Tested locally" is not an answer.
• The issue it closes, if any.

2. Title

<type>(<scope>): <description>

• type: feat fix docs style refactor test chore perf build ci revert. Lowercase. On main the distribution is roughly feat 166 / fix 122 / docs 76 / chore 18 / refactor 14.
• scope: the component the diff touches — embodiment, libero, realworld, readme, docker, collective, openpi_pytorch. Optional; drop it rather than invent one. [a-z0-9_-] only — a space, slash, dot or capital fails CI. feat(new) (PR #1421) passes CI but is the anti-pattern the linter warns on: it names the PR, not the code.
• description: ≤ 50 characters, and that is the part after : , not the whole title. This is the rule PRs fail most often. It must start with a lowercase a-z (so support 5D parallelism, never 5D parallelism support), stay imperative, carry no trailing period, and use plain ASCII — π₀ in a title fails the check. add MolmoAct2 LIBERO evaluation support, not Added support for MolmoAct2.
• Never append (#123) — GitHub adds it at squash-merge.

Fitting 50 characters is the whole discipline of the title: name the one change a reviewer needs to see in the PR list, and let the body carry the rest. If the PR does several things, title it after the largest and enumerate in Description.

Check just the title, no body needed:

python3 .agents/skills/create-pr/lint_pr.py lint --title "feat(new): add stuff."

3. Body

Start from the skeleton so no section goes missing:

python3 .agents/skills/create-pr/lint_pr.py template > /tmp/pr-body.md

Then fill it in. Keep all six headings, even where a section is one line. What each one is for:

Style rules the linter enforces:

• No leading indentation. Not on headings, not on paragraphs, not on table rows. Four spaces turns a paragraph into a code block; a table whose header and rows disagree on indent does not render as a table at all.
• Delete the <!--- ... --> hints once a section is written.
• Nothing above the first ### heading — put it in Description.
• One line per paragraph. GitHub reflows; hard wraps only survive until someone edits the body.