diff --git a/.claude/skills/update-nlopt/SKILL.md b/.claude/skills/update-nlopt/SKILL.md
new file mode 100644
index 0000000..8df590e
--- /dev/null
+++ b/.claude/skills/update-nlopt/SKILL.md
@@ -0,0 +1,75 @@
+---
+name: update-nlopt
+description: Bump the vendored nlopt C library (extern/nlopt submodule) to a new upstream release, and understand how that flows through to a PyPI publish. Use when asked to "update nlopt", "bump nlopt version", or similar.
+---
+
+# Updating the vendored nlopt version
+
+This package wraps the upstream C library [nlopt](https://github.com/stevengj/nlopt),
+vendored as the `extern/nlopt` git submodule. The Python package version is **not**
+tracked separately — `setup.py` derives it at build time by regex-parsing
+`NLOPT_MAJOR_VERSION` / `NLOPT_MINOR_VERSION` / `NLOPT_BUGFIX_VERSION` out of
+`extern/nlopt/CMakeLists.txt`. There is no `pyproject.toml` version, no `__init__.py`
+version, nothing else to edit for a routine bump.
+
+## 1. Bump the submodule to a specific release tag
+
+Pin to an exact upstream tag rather than `git submodule update --remote` (which floats
+to the tip of whatever branch the submodule tracks, potentially landing on unreleased
+commits past the last tag):
+
+```shell
+cd extern/nlopt
+git fetch --tags
+git tag --list "v*" --sort=-v:refname | head   # find the latest release tag
+git checkout vX.Y.Z
+cd ../..
+git add extern/nlopt
+git commit -m "Bump nlopt submodule to vX.Y.Z"
+```
+
+Sanity-check the version macros landed correctly:
+
+```shell
+grep -oP 'NLOPT_(MAJOR|MINOR|BUGFIX)_VERSION *"\K[^"]+' extern/nlopt/CMakeLists.txt
+```
+
+This should print the three version components matching the tag you checked out —
+this is exactly what `setup.py` and the CI "already published on PyPI" guard
+(`.github/workflows/wc-build.yml`, "Ensure version is not already published on PyPI"
+step) both parse to compute the package version.
+
+## 2. Check whether CI's OS/Python matrix needs touching
+
+Almost never required for a routine nlopt bump — only if the new release changes which
+Python versions or platforms are supported:
+
+- `.github/workflows/build.yml` — `os` / `python-versions` inputs passed to the
+  reusable `wc-build.yml`, used for PR builds and release-triggered publishes.
+- `.github/workflows/manual-deploy.yml` — the same OS/Python choices, exposed as
+  `workflow_dispatch` checkboxes for on-demand testpypi/pypi builds.
+
+There is no manylinux Dockerfile step anymore (CI uses the prebuilt
+`quay.io/pypa/manylinux_2_28_x86_64` / `..._aarch64` images directly in
+`wc-build.yml`) and no hardcoded `CIBW_BUILD` list to hand-edit — it's derived
+from the `python-versions` input.
+
+## 3. Verify via CI, not locally
+
+Push the branch and open a PR against `master`. `build.yml`'s `pull_request` trigger
+runs `wc-build.yml` with `target: none`, which builds wheels across the full OS/Python
+matrix and runs `extern/nlopt/test/t_python.py` against each installed wheel — this is
+the real regression check. `test_scripts/sample_test_script.py` is available as an
+optional extra manual smoke test if you want to exercise a specific solver locally.
+
+## 4. Optional dry-run publish
+
+Trigger `manual-deploy.yml` via `workflow_dispatch` with `target: testpypi` to validate
+the full build+upload path (including the version-suffix auto-generation for testpypi's
+14-day immutability rule) before a real release.
+
+## 5. Real release
+
+Cut a GitHub Release (tag `vX.Y.Z`, matching the nlopt version). `build.yml`'s
+`release: published` trigger runs `wc-build.yml` with `target: pypi`, which builds,
+tests, and publishes via trusted OIDC publishing — no manual `twine upload` needed.
diff --git a/.github/setup.md b/.github/setup.md
deleted file mode 100644
index 2ab76d1..0000000
--- a/.github/setup.md
+++ /dev/null
@@ -1,29 +0,0 @@
-How to Update
-=============
-
-1. Update nlopt submodule
-   ```shell
-   git submodule update --remote
-   # if there are changes
-   git add extern/
-   git commit -m "Update nlopt submodule"
-   ```
-2. `[Optional]` If there is a need, update the `ci/nlopt_manylinux2014_x64_64.Dockerfile` image. This is used to build
-   the linux images
-    * This should be done in `image/*` branch as the github action `manylinux-image.yml` will automatically update the
-      image in dockerhub on push.
-    * Whenever there is a upgrade to Python's minor version, it is likely that the manylinux image will not have that
-      version. Go to https://quay.io/repository/pypa/manylinux2014_x86_64?tab=tags and change the image version 
-      accordingly.
-3. Update `.github/workflows/build.yaml` if necessary
-    * Search for lines: `python-version`, `CIBW_BUILD`
-4. There are already tests in the github workflows to test that `pip install nlopt` works. But none to test the module specifically
-   1. Spin up a docker image and run the sample code
-   2. ```shell
-      docker container run -it --rm --entrypoint bash python:3.10-slim-buster
-      pip install nlopt
-      apt-get update
-      apt-get install curl -y
-      curl https://raw.githubusercontent.com/DanielBok/nlopt-python/master/test_scripts/sample_test_script.py --output test.py
-      python test.py
-      ```
diff --git a/extern/nlopt b/extern/nlopt
index 8dea251..88c424d 160000
--- a/extern/nlopt
+++ b/extern/nlopt
@@ -1 +1 @@
-Subproject commit 8dea25183daeb7f601c7469ca2a45e8c580a5688
+Subproject commit 88c424d4f458412787df96fcc95218acbca224fd