diff --git a/RELEASING.md b/RELEASING.md
deleted file mode 100644
index 4aea823..0000000
--- a/RELEASING.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# Release automation
-
-This repository now uses `semantic-release` to turn Conventional Commits on
-`main` into version bumps, changelog updates, and published GitHub releases.
-That keeps the existing publish workflow focused on the two package registries:
-JSR and npm.
-
-## Why this replaces Forge here
-
-`okikio/undent` uses `@roka/forge` as a Deno task plus three workflows:
-
-1. a manual **bump** workflow that opens a version/changelog PR
-2. a **release** workflow that creates a draft GitHub Release after that PR is
-   merged
-3. a **publish** workflow that runs after the draft is manually published
-
-That flow works well for Deno workspaces, but it is heavier than this repo
-needs:
-
-- it adds a bump PR before every release
-- it adds a second manual draft-release step before publishing
-- it only supports `deno.json`, while this repo currently uses `deno.jsonc`
-- it still needs a personal access token so the draft release can trigger the
-  publish workflow
-
-For a single-package library with an existing `publish.yml` release trigger,
-`semantic-release` is the smallest way to get automatic SemVer bumps and
-autogenerated changelogs without that extra PR and draft-release ceremony.
-
-## Chosen release flow
-
-```text
-push to main
-    │
-    ├─► CI validates fmt, lint, types, docs, tests, and npm build
-    │
-    └─► Release workflow runs semantic-release
-            │
-            ├─► analyzes Conventional Commits
-            ├─► calculates the next SemVer version
-            ├─► updates CHANGELOG.md
-            ├─► updates deno.jsonc version
-            ├─► commits chore(release): x.y.z [skip ci]
-            └─► publishes a GitHub Release
-                      │
-                      └─► publish.yml pushes the same version to JSR and npm
-```
-
-The workflow uses a dedicated `RELEASE_TOKEN` secret because releases created by
-the default GitHub Actions token do not trigger downstream `release` workflows.
-Using a token with `contents: write` keeps the existing `publish.yml` trigger
-working.
-
-## Files involved
-
-- `.github/workflows/release.yml` runs `semantic-release` on pushes to `main`
-- `.releaserc.json` controls versioning, changelog generation, and release
-  commits
-- `scripts/update_release_version.ts` rewrites `deno.jsonc` during the release
-  prepare step
-- `CHANGELOG.md` becomes the generated release history
-- `.github/workflows/publish.yml` stays responsible for JSR and npm publishing
-
-## Alternatives considered
-
-### `release-please`
-
-Good option if you want a reviewable release PR. It updates changelogs and
-versions reliably, but its release-PR model adds the same PR-based ceremony this
-repo aims to avoid.
-
-### `changesets`
-
-Excellent for monorepos and coordinated multi-package releases. It is more
-manual here because every releasable PR needs a changeset file, which adds more
-release bookkeeping than a single-package library needs.
-
-### `release-it`
-
-Flexible and mature, especially when combined with the conventional-changelog
-plugin. It needs more custom scripting than `semantic-release` to infer the next
-version from commit history and to keep `deno.jsonc` in sync.
-
-### JSR and Deno-native options
-
-- `@roka/forge`: best fit for Deno workspaces, but the bump-PR plus
-  draft-release flow is more hands-on than needed for this single-package
-  library
-- `@deno/bump-workspaces`: promising for Deno workspaces, but it is
-  workspace-first and centered on pull-request driven bumps
-- `@eser/codebase/release`: Deno-native and capable of version bump + changelog
-  orchestration, but you choose the bump type manually instead of deriving it
-  from commit history
-- `@tene/version-bump`: good low-level version bump utility, but it does not
-  cover changelog generation and GitHub release creation by itself
-
-## One-time setup
-
-1. Add a `RELEASE_TOKEN` repository secret with `contents: write`
-2. Keep branch protection pointed at the normal CI workflow
-3. Merge Conventional Commit messages into `main`
-
-After that, the release workflow can stay hands-off for normal releases.