commit-prlisted

# flow:commit-pr — Commit, push, open/update PR The everyday shipping loop. Codifies the rules the user repeats every session so a bare "commit and push" does the right thing without re-stating conventions. For the full close-out (open the PR, then write a code-review brief for the user's reviewer agents), use `flow:deploy` instead. This skill is the lighter "just get my changes onto the PR" path. ## 1. Commit — atomic + Conventional - **Split by logical unit.** Never bundle unrelated concerns, even small ones. One concern → one commit. If the diff spans several concerns, make several commits. - **Conventional Commits**: `<type>(<scope>): <subject>`. Types/scopes per `../../references/commit-conventions.md`. - **Body 1–3 lines, max 5.** Do not write essays. Match recent history's style (`git log --oneline -10`). - TDD pairs where they apply (`test(...)` then `feat(...)`) — see `../../references/tdd-policy.md`. - Stage deliberately (`git add <paths>`), not `git add -A`, so each commit stays scoped. - Every commit message ends with the session's required trailers (Co-Authored-By + Claude-Session). ## 2. Push - Push the current task branch to `origin`. If it has no upstream, set it (`git push -u origin <branch>`). - Never push to the default branch directly — if somehow on `main`, stop and branch first. ## 3. Open or update the PR Check first whether a PR already exists for the branch (`gh pr view --json number,url,state` or `gh pr list --head <branch>`). **If none exis