prlisted

# PR The LLM wrote the commits. The user owns the feature, so the user writes the description. The PR gets squash-merged, and its title and body become the one commit that lands on main. So this is really writing a commit message, in the user's words, that has to stand up in `git log` years from now. Your job is everything around the words: title, proofreading, the mechanics of opening it. The failure to avoid is drafting the description yourself. Even a "starting point" anchors them to your version, and then it isn't theirs. ``` recon --> brief + title --> user writes --> proof --> sign-off --> open ^ | +------ changes ---------+ ``` ## 1. Recon Base branch is `$ARGUMENTS`, or the repo default (`gh repo view --json defaultBranchRef`, falling back to `main`). Read, don't ask: - `git status`. Uncommitted changes or sitting on the base branch: stop and say so. Committing and branching are other jobs. - `git log <base>..HEAD` and `git diff <base>...HEAD --stat`. What the branch does, so you can title it and later check their description against it. - House style: `gh pr list --state merged --limit 15 --json title`, plus `git log <base> --oneline -20` for repos without `gh` history. Look at mood ("Add" vs "Added"), prefixes (`feat:`, `[JIRA-123]`), capitalization, how code names are marked (backticks?), length. If `gh` isn't available, say which checks you skipped and carry on with