docs: refer to semantic-release instead of release-please

[frankieyan]

Short description

Updates various docs to remove references to release-please, as we've already moved onto semantic-release in #1024.

PR Checklist

• Updated docs (storybooks, readme)

[doistbot]

This PR swaps out release-please references for semantic-release across the docs, README, and PR template to reflect the move made in #1024.

I also included a few optional follow-up notes in the details below.

Optional follow-up notes (3)

• README.md:230: The new sentence lists feat:, fix:, feat!: and fix!: as releasing commits but omits perf:. With the conventionalcommits preset used in release.config.js, perf: also triggers a patch release. Consider adding it to the list (e.g., feat:, fix:, perf:, and their ! variants) to match the actual semantic-release behavior.
• AGENTS.md:117: This blank line (and the one added at L224) sits inside the <!-- shared-config:agents --> ... <!-- /shared-config:agents --> region. Per the file's own header, everything below the shared-config:agents marker is synced from Doist/shared-configs and must not be edited directly — these additions will be overwritten on the next sync. If the spacing is desired, it should be added upstream in shared-configs instead.
• README.md:228: This bullet is under the "semantic-release:" header, but semantic-release only publishes to npm (the npx semantic-release step). The GitHub Packages publish is a separate npm publish step later in publish-package-release.yml. As written, it attributes both registries to semantic-release, which would mislead anyone debugging a GitHub Packages publish failure toward the wrong step. Either drop "and GitHub Packages" here or call out the separate publish step.

_{Share Feedback • Review Logs}

[doistbot]

semantic-release's configured commit analyzer reads Git commit messages, not GitHub PR metadata. PR titles can differ from the resulting commits (for example with rebase merges), so describe versioning in terms of conventional commit messages and align the README guidance with that source of truth.

[frankieyan]

@doistbot we squash commits in this repo with the commit message defaulting to the PR title. Rarely will the final message deviate so I think this should be clear enough.

[doistbot]

That makes “PR title” a practical shorthand for this repository, since squash merges normally carry it into the resulting commit. However, semantic-release itself doesn’t read GitHub PR metadata: release.config.js uses @semantic-release/commit-analyzer, which analyzes commit messages on main.

I’d keep the wording technically precise and mention the workflow explicitly:

Versioning is automated by semantic-release based on conventional commit messages. With squash merges, the resulting commit message normally defaults to the PR title.

That preserves the current practice without implying the PR title is semantic-release’s source of truth.

[frankieyan]

You are technically right, but I'm gonna overrule this and say this is ok 😎 (let's see if your human colleague disagrees)

[doist-release-bot]

🎉 This PR is included in version 34.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀