diff --git a/.github/workflows/rebuild-sandbox-template.yml b/.github/workflows/rebuild-sandbox-template.yml
new file mode 100644
index 00000000..0f86be75
--- /dev/null
+++ b/.github/workflows/rebuild-sandbox-template.yml
@@ -0,0 +1,75 @@
+## Rebuilds the internal-slack-agent sandbox images when this repository moves.
+##
+## Copy of e2b-dev/product-harness's workflow of the same name, retargeted at this repo.
+## Belongs at `.github/workflows/rebuild-sandbox-template.yml` in e2b-dev/docs; the
+## authoritative source is `handoff/e2b-dev-docs/` in e2b-dev/internal-slack-agent.
+##
+## The images bake a clone of this repository at /home/user/workspace/docs — agents read
+## the docs off disk instead of cloning them per turn — so a commit here only reaches an
+## agent after a template rebuild. `POST /template/rebuild` does both halves: it stages a
+## fresh build context in a sandbox, then starts the image build. Every rebuild restages
+## *every* harness, so calling from here also picks up whatever product-harness and
+## architect-harness have on main.
+##
+## This repo ships no skills, so it contributes nothing to the deployment's skill
+## registry; the rebuild's other KV payload, the entity-link map, is derived from the
+## harnesses that publish record IDs and not from this one. What a push here changes is
+## the image, and nothing else.
+##
+## Staging is awaited, so a commit that breaks it (an unclonable ref, a tree the SDK
+## cannot pack) fails this job. The image build takes minutes and is followed at
+## `GET /template/status` on the deployment.
+##
+## Both deployments, deliberately. Each builds its own template name — production
+## `claude-smol`, staging `claude-smol-staging` — so the two rebuilds cannot race each
+## other for a tag, and a deployment's KV payloads refresh only when it is called itself.
+## One job per deployment, so a failing staging deployment cannot block production picking
+## up the commit, and vice versa. Wiring only the staging pair means deleting the
+## `rebuild-prod` job rather than leaving it to fail on an empty URL.
+name: Rebuild sandbox template
+
+on:
+  push:
+    branches: [main]
+  workflow_dispatch:
+
+## Nothing here touches the repository or the GitHub API: no checkout, no `gh`, no
+## uploads. So the job needs no token scopes at all, which is stricter than the
+## `contents: read` a default block would grant.
+permissions: {}
+
+jobs:
+  ## Two rebuilds at once would move the same template tag, and the deployment refuses
+  ## the second anyway; queueing keeps the newer commit from being dropped. The group is
+  ## per deployment so the two jobs never queue behind each other.
+  rebuild-staging:
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    concurrency:
+      group: sandbox-template-rebuild-staging
+    steps:
+      - name: Stage harnesses and start template build (staging)
+        env:
+          SITE_URL: ${{ secrets.TEMPLATE_REBUILD_URL_STAGING }}
+          TEMPLATE_BUILD_SECRET: ${{ secrets.TEMPLATE_BUILD_SECRET_STAGING }}
+        run: |
+          curl --fail-with-body -sS -X POST "$SITE_URL/template/rebuild" \
+            -H "x-template-secret: $TEMPLATE_BUILD_SECRET" \
+            -H 'content-type: application/json' \
+            -d "{\"sha\":\"$GITHUB_SHA\"}"
+
+  rebuild-prod:
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    concurrency:
+      group: sandbox-template-rebuild-prod
+    steps:
+      - name: Stage harnesses and start template build (production)
+        env:
+          SITE_URL: ${{ secrets.TEMPLATE_REBUILD_URL_PROD }}
+          TEMPLATE_BUILD_SECRET: ${{ secrets.TEMPLATE_BUILD_SECRET_PROD }}
+        run: |
+          curl --fail-with-body -sS -X POST "$SITE_URL/template/rebuild" \
+            -H "x-template-secret: $TEMPLATE_BUILD_SECRET" \
+            -H 'content-type: application/json' \
+            -d "{\"sha\":\"$GITHUB_SHA\"}"