push-py4vasp

name	push-py4vasp
description	Push py4vasp changes to origin and open a PR. Use when asked to push, publish the branch, ship the changes, or open a pull request for py4vasp. Reviews code changes first (dispatches /review-py4vasp to a subagent unless already done), applies black + isort, pushes a fresh descriptive branch to origin, and hands back a PR compare link plus a draft PR message.

Push py4vasp to origin

Orchestrates the last mile: review → format → push → PR link. The deterministic prep (classify changes, decide if review is needed, suggest a branch name, build the PR URL and draft message) is done by the read-only driver .claude/skills/push-py4vasp/push_prep.py; the side-effecting steps (dispatch review, apply fixes, format, push) are orchestrated here. origin is the main repo vasp-dev/py4vasp, so pushing publishes to upstream. Paths are relative to the repo/worktree root.

Step 0 — prep (run the driver)

python .claude/skills/push-py4vasp/push_prep.py

It prints: changed files split into CODE (*.py under src/ or tests/) vs non-code (docs/CI/tooling); whether a review is required; a suggested branch name; the PR compare URL; and a draft PR message. Read this first — it drives every decision below.

Step 1 — review gate (only if CODE changed)

If the driver reports no code changes (only docs/CI/tooling), skip to Step 3.

If code changed, a py4vasp review must exist for this diff:

• If you already ran /review-py4vasp on this diff earlier in the session and its findings were addressed, skip re-running it.
• If you cannot tell whether a review was done, ask the user before dispatching.
• Otherwise dispatch a subagent to review: use the Agent tool (subagent_type: general-purpose) and instruct it to follow the /review-py4vasp skill on the current diff and return the findings.

Then address the findings — fix the code, or record why a finding is a non-issue. Re-run the affected tests (see /review-py4vasp for the invocation).

Step 2 — confirm (hard stop before publishing)

STOP and ask the user to confirm before formatting and pushing. Pushing publishes the branch to origin (vasp-dev/py4vasp) — do not proceed without an explicit go-ahead.

Step 3 — format

Apply the project's formatters to src and tests (no-op if pre-commit already ran):

uv run --active black src tests

uv run --active isort src tests

Then look at the reformatted diff: black sometimes introduces awkward line breaks (a long call or expression wrapped across several lines). Where that hurts readability, extract a well-named helper variable so the line fits naturally, and re-run black to confirm it stays put.

If either step changed files, commit that:

git commit -am "Apply black and isort"

Step 4 — branch + push

Create a fresh descriptive branch (start from the driver's suggestion, refine if it misses the point), then push it and set upstream:

git switch -c feat/<descriptive-name>

git push -u origin feat/<descriptive-name>

Step 5 — PR link + message

Give the user the compare URL and the draft message from Step 0 (the driver already built both, using the real branch name if you kept its suggestion — else swap the branch segment). The URL opens GitHub's "Open a pull request" page:

https://github.com/vasp-dev/py4vasp/compare/master...<branch>?expand=1

Present the draft PR message in a copy-paste block.

Gotchas

• origin is upstream, not a fork. [e-mail]:vasp-dev/py4vasp.git. Pushing goes straight to the main repo (the user is a maintainer). A fork remote private (martin-schlipf/py4vasp) also exists — only use it if the user asks.
• gh is not installed here (only glab). Do not reach for gh pr create; hand over the constructed compare URL instead — the driver builds it from remote.origin.url.
• Non-code = review-skipped, but still formatted + pushed. A docs/CI/tooling change goes straight from Step 0 to Step 3.
• The driver is read-only. push_prep.py never pushes, commits, or edits; re-run it freely. The only publishing action is git push in Step 4.
• Worktree note: run inside the worktree you actually changed; the driver reports the checkout path so you can confirm.

Human path

A developer does the same by hand: review the diff, uv run --active black src tests && uv run --active isort src tests, git push -u origin <branch>, then open the compare URL in a browser.