creating-pull-requestslisted

# Creating Pull Requests How DorkOS PRs are opened and how the automated Claude review behaves on them. This repo is routinely multi-agent, so the mechanics below keep PRs clean and the review loop cheap. ## When to use - You are about to open a PR (from an agent or by hand). - A PR already has review feedback and you want another pass once it is addressed. - You want to dial a PR's review up, down, or off. ## Before you open: branch from a worktree Code PRs come from an isolated worktree, never the shared `main` checkout (see the `working-in-worktrees` skill). Base the worktree on `origin/main`, not local `main`, so the PR diff contains only your changes: ```bash git fetch origin git gtr new <branch> --from origin/main --yes # the repo's worktree helper ``` Commit conventions and the pre-push gate live in the `git:commit` / `git:push` commands. End commit messages with the `Co-Authored-By` trailer. ## Include a changelog fragment A PR with user-facing changes must include a **changelog fragment** under `changelog/unreleased/` — one file per change (`<YYMMDD-HHMMSS>-<slug>.md`; see `changelog/README.md`). The `post-commit` hook usually writes one from your commit subject; **verify it exists and curate it** (rewrite for a user, fix the category, add a `(#PR)` ref) before opening the PR. Rewriting the prose is always safe: the PR check reads the fragment's `covers:` frontmatter, not its wording. Write one by hand if the hook skipped it or phrased it poorly, and give