diff --git a/RELEASING.md b/RELEASING.md
index 899bccb..c837df8 100644
--- a/RELEASING.md
+++ b/RELEASING.md
@@ -33,104 +33,7 @@ where the bump label was forgotten.
 
 ---
 
-## Cutting v0.1.0 (initial release) — full runbook
-
-The first release is intentionally manual because `auto` needs a baseline
-tag (`v0.1.0`) to start counting PR labels from. After 0.1.0 the
-label-driven workflow takes over.
-
-### Step 0 — prerequisites (one-time, on the maintainer's machine)
-
-```bash
-# Ensure local build tooling is available
-pip install --upgrade build twine
-
-# Optional but recommended: install auto so you can dry-run locally
-npm install -g auto    # or use the binary download path from release.yml
-
-# Ensure your PyPI account has write access to the bids-utils project,
-# OR that you have a project-scoped API token for it
-```
-
-### Step 1 — merge the release-pipeline branch
-
-Merge the `enh-auto-release` PR (containing `.autorc`,
-`.github/workflows/release.yml`, `CHANGELOG.md`, `RELEASING.md`,
-CONTRIBUTING.md updates) into `main`. The first release CANNOT proceed
-until this is on `main`, because `release.yml` and the `auto` config are
-what wire everything together.
-
-### Step 2 — create repo labels and the PyPI token (one-time, on GitHub side)
-
-```bash
-# Create the auto release labels (major, minor, patch, release, ...)
-GH_TOKEN=$(git config hub.oauthtoken) intuit-auto create-labels
-```
-
-Then on the GitHub web UI:
-
-1. Generate a project-scoped API token at
-   <https://pypi.org/manage/account/token/> (scoped to `bids-utils`).
-2. Add it as repo secret `PYPI_TOKEN` under
-   *Settings → Secrets and variables → Actions*.
-
-If you prefer OIDC-based publishing without a long-lived token, see
-"Optional: PyPI Trusted Publishing" below — equivalent end-state, just a
-different setup.
-
-### Step 3 — cut the tag and publish
-
-```bash
-# 1. Make sure you're on main and clean
-git checkout main
-git pull --ff-only
-git status   # must be clean
-
-# 2. Run the full local test suite as a final gate
-tox
-
-# 3. Sanity-check what hatch-vcs will produce AT the tag
-#    (without the tag, this shows a 0.1.devNN+gSHA dev version)
-python -m build
-ls dist/
-rm -rf dist/   # discard the dev-version artifacts; we'll rebuild at the tag
-
-# 4. Tag v0.1.0 and push the tag
-git tag -a v0.1.0 -m "v0.1.0"
-git push origin v0.1.0
-
-# 5. Build the release artifacts from the tagged commit
-python -m build
-ls dist/
-# Expect: bids_utils-0.1.0-py3-none-any.whl  AND  bids_utils-0.1.0.tar.gz
-
-# 6. (Optional but recommended) twine check before upload
-twine check dist/*
-
-# 7. Upload to PyPI
-twine upload dist/*
-#   When prompted:
-#     Username: __token__
-#     Password: <the project-scoped pypi token from Step 2>
-
-# 8. Create the GitHub release with the CHANGELOG entry as the body
-gh release create v0.1.0 --title "v0.1.0" \
-    --notes "$(awk '/^# v0\.1\.0/,/^---$/' CHANGELOG.md | sed '$d')"
-```
-
-### Step 4 — sanity-check the release
-
-```bash
-# Verify the artifact is up on PyPI
-pip index versions bids-utils
-
-# Verify a fresh install works
-python -m venv /tmp/bids-utils-smoke && \
-    /tmp/bids-utils-smoke/bin/pip install bids-utils==0.1.0 && \
-    /tmp/bids-utils-smoke/bin/bids-utils --help
-```
-
-### Step 5 — confirm the release.yml workflow is healthy
+### Step 5 (TODO) — confirm the release.yml workflow is healthy
 
 After v0.1.0 is tagged, the next merge to `main` will trigger
 `release.yml`. If that merged PR has no `release` label, the workflow