robosystems: Command for Claude Code

Create a GitHub pull request for the current branch, writing the title and description from the actual work done in this session — not reconstructed from the diff.

Why this command exists

The previous flow outsourced PR-description authoring to a GitHub Action that only saw the diff and commit messages. It could not know why the changes were made, so it frequently described things that weren't true. Those inaccurate descriptions then fed @claude reviews, compounding the bad information. This command fixes that at the root: you author the description here, where the full context of what was done and why is available.

This is a Python backend service (FastAPI + LadybugDB graphs, managed with uv and just). Ground every description in the actual code that changed, and stay mindful of multi-tenancy (graph operations scoped to graph_id).

This repository is public. The PR title and body are world-readable the moment they're pushed — routinely before the change is deployed, since deploys are manual. Treat the description as a publication, not a work note.

Instructions

1. Preflight

Run these checks before touching anything:

# Current and target branches
CURRENT=$(git branch --show-current)
TARGET=${1:-main}            # override target via the first argument

• Never PR from the default branch. If CURRENT is main (or master/staging), stop and tell the user to switch to a feature branch first.
• Source ≠ target. If CURRENT == TARGET, stop.
• Uncommitted changes. Run git status --porcelain. If there are uncommitted/staged changes, surface them and ask whether to commit them (respecting the repo's commit rules — never on main, stage files by name, no git add -A) or proceed without them. The PR description must reflect committed state.
• Existing PR. Check gh pr list --head "$CURRENT" --base "$TARGET" --json url,number. If a PR already exists, do not create a duplicate — offer to update its title/body with gh pr edit instead.
• Security fixes — check deployment first. A security-fix commit discloses the bug through its diff the moment it's pushed. If this branch carries one, check whether the vulnerable code is still live in production (git show <prod-tag>:<file> against the fix) and tell the user, so they can sequence the deploy with — or ahead of — the public push rather than opening a window.
• Push the branch. gh pr create requires the branch on the remote. Ensure it's pushed: git push -u origin "$CURRENT" (the user invoking /create-pr is the explicit, in-the-moment request that authorizes pushing this feature branch — this is the one push allowed without a separate ask; never push main).