publish-prlisted

# Publish PR Take whatever is in the working tree right now and turn it into an open pull request: figure out what should go in, commit it, push the branch, and open the PR. Nothing more. The job is deliberately narrow. "Is the code correct?" and "should this be merged?" are real questions, but they belong to other tools (a verify step, CI, a human reviewer, a future `merge-pr`). Folding them in here would make the one-shot slow and ambiguous, so this skill leaves them out on purpose. ## Workflow ### 1. See what's actually there ```bash git status -sb git diff HEAD git branch --show-current ``` Read the diff before touching anything. You need to know what's staged, what's unstaged, and whether the current branch is a shared default branch. ### 2. Decide scope before staging If everything in the tree clearly belongs to one change, stage it all. But if the tree is **mixed** — unrelated edits, stray debug prints, an unrelated file — do not reach for `git add -A`. Silently sweeping unrelated work into someone's PR is the kind of mistake that's annoying to unwind. Ask which files belong, then stage those paths explicitly. ### 3. Branch if you're on the default branch If the current branch is `main` / `master` / the repo's default, create a new branch first — committing straight onto a shared default branch is what you're trying to avoid by opening a PR at all. Use a short, descriptive branch name derived from the change; if the repo has an obvious branch-naming conventio