ci: revert to squash-merge

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,7 +1,6 @@
 <!-- Provide a general summary of your changes in the Title above. -->
-<!-- The title has no required format, but every commit in the PR must be -->
-<!-- a Conventional Commit (e.g. "fix: ..." or "feat: ...") — see -->
-<!-- CONTRIBUTING.md#pull-requests. release-please reads commits directly. -->
+<!-- The title must be a Conventional Commit (e.g. "fix: ..." or "feat: ...") -->
+<!-- see CONTRIBUTING.md#pull-request-titles — it becomes the changelog entry. -->
 
 #### Description
 

.github/workflows/CI.yml

@@ -59,10 +59,11 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
-  commit-lint:
+  pr-title:
     runs-on: ubuntu-latest
+    permissions:
+      pull-requests: read
     steps:
-      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6
-        with:
-          fetch-depth: 0
-      - uses: wagoid/commitlint-github-action@6cf16efdf4da5277c791d335142c03a0bdf1766e # v6.2.1
+      - uses: amannn/action-semantic-pull-request@48f256284bd46cdaab1048c3721360e808335d50 # v6
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

AGENTS.md

@@ -82,7 +82,7 @@ The git backend minimizes subprocess spawns (currently 3 git invocations) since
 
 - Style: prefer `test` over `[ ]`; prefer `&&`/`||` over `and`/`or` for simple conditionals, `if`/`else`/`else if` for anything more complex; prefer piping over command substitution when it doesn't require extra commands.
 - Naming: everything `snake_case`. User-facing names (variables, functions, files) are prefixed `tide_`; internal-only names are prefixed `_tide_`. Items live in `_tide_item_<name>.fish`; subcommands in `_tide_sub_<name>.fish`.
-- PRs merge via a real merge commit (not squash), so every commit — not the PR title — must follow [Conventional Commits][conventional-commits] (`<type>[(scope)][!]: <description>`); [release-please][release-please] reads commits directly off `main` to generate the changelog. This is CI-enforced per-commit.
+- PR titles must follow [Conventional Commits][conventional-commits] (`<type>[(scope)][!]: <description>`) — PRs are squash-merged, so the PR title becomes the commit message on `main`, and [release-please][release-please] reads it to generate the changelog. This is CI-enforced.
 - Releases are fully automated by release-please; don't hand-edit `functions/tide.fish`'s version string or the floating `vN`/`vN.M` tags.
 
 [clownfish]: https://github.com/IlanCosman/clownfish

CONTRIBUTING.md

@@ -19,26 +19,21 @@ If you have any questions that aren't addressed in this document, please don't h
 
 ### Pull Requests
 
-PRs are merged into `main` with a real merge commit, not squashed. Because of
-that, every commit in the PR — not just the title — must follow
-[Conventional Commits][]: `<type>[(scope)][!]: <description>`, e.g.
-`fix: correct jj branch color` or `feat(vcs)!: unify git/jj into a single
-item`. [release-please][] reads these commits directly off `main` to
-generate the next release's changelog entry. A CI check (`commit-lint`)
-enforces this on every commit in the PR.
+PR titles must follow [Conventional Commits][]: `<type>[(scope)][!]: <description>`,
+e.g. `fix: correct jj branch color` or `feat(vcs)!: unify git/jj into a single item`.
 
 - Allowed types: `feat`, `fix`, `build`, `chore`, `ci`, `docs`, `style`, `refactor`, `perf`, `test`, `revert`.
 - Add `!` before the `:` (or a `BREAKING CHANGE:` footer) for breaking changes.
 
-The PR title itself has no format requirement — write it as plain,
-descriptive text for anyone skimming the PR list.
+This isn't just style: since PRs are squash-merged, the title becomes the
+commit message on `main`, which [release-please][] reads to generate the
+next release's changelog entry. A CI check enforces this on every PR.
 
 Each pull request should only impact a single `<type>(scope)`. In other words,
-a PR with only `fix: correct branch color` commits or only
-`feat(foobar): ...` commits is acceptable, but mixing `perf(docker): ...` and
-`perf(kubectl): ...` commits in the same PR is not.
+`fix: correct branch color` or `feat(foobar): introduce foobar item` are
+acceptable, but `perf(items): improve both docker and kubectl` is not.
 
-This is to keep the changelog generating cleanly off `main`'s commit history.
+This is to ensure that the changelog generates cleanly off of PR titles.
 
 ### Naming Conventions
 
@@ -116,11 +111,8 @@ All links should be in reference style, with references at the bottom of the doc
 
 Releases are automated by [release-please][]. It watches `main` and keeps an
 open "release PR" containing the next version bump and a generated
-`CHANGELOG.md` entry, derived from Conventional Commit messages on `main`
-since the last release. Merge commits themselves carry GitHub's default
-message ("Merge pull request #N from branch"), which never matches the
-Conventional Commits pattern, so release-please skips them and reads only
-the PR's individual commits.
+`CHANGELOG.md` entry, derived from Conventional Commit PR titles merged
+since the last release.
 
 - [ ] Before merging the release PR, hand-edit its `CHANGELOG.md` diff to
       clean up the generated bullets into prose, and add any narrative