diff --git a/.github/workflows/automerge.yml b/.github/workflows/automerge.yml
new file mode 100644
index 0000000000..4f70acfbcb
--- /dev/null
+++ b/.github/workflows/automerge.yml
@@ -0,0 +1,27 @@
+name: automerge
+on:
+  pull_request:
+    types:
+      - labeled
+      - unlabeled
+      - synchronize
+      - opened
+      - edited
+      - ready_for_review
+      - reopened
+      - unlocked
+  pull_request_review:
+    types:
+      - submitted
+  check_suite:
+    types:
+      - completed
+  status: {}
+jobs:
+  automerge:
+    runs-on: ubuntu-latest
+    steps:
+      - name: automerge
+        uses: "pascalgn/automerge-action@v0.12.0"
+        env:
+          GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
diff --git a/setup.cfg b/setup.cfg
index 9d41be119c..4eb5018390 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -57,7 +57,7 @@ docs =
     # Keep these in sync with docs/requirements.txt
 	# upstream
 	sphinx
-	jaraco.packaging >= 6.1
+	jaraco.packaging >= 8.2
 	rst.linker >= 1.9
 
 	# local
diff --git a/skeleton.md b/skeleton.md
index ec421c2598..dd8ec014cd 100644
--- a/skeleton.md
+++ b/skeleton.md
@@ -46,6 +46,26 @@ For example, here's a session of the [path project](https://pypi.org/project/pat
 
 Thereafter, the target project can make whatever customizations it deems relevant to the scaffolding. The project may even at some point decide that the divergence is too great to merit renewed merging with the original skeleton. This approach applies maximal guidance while creating minimal constraints.
 
+## Periodic Collapse
+
+In late 2020, this project [introduced](https://github.com/jaraco/skeleton/issues/27) the idea of a periodic but infrequent (O(years)) collapse of commits to limit the number of commits a new consumer will need to accept to adopt the skeleton.
+
+The full history of commits is collapsed into a single commit and that commit becomes the new mainline head.
+
+When one of these collapse operations happens, any project that previously pulled from the skeleton will no longer have a related history with that new main branch. For those projects, the skeleton provides a "handoff" branch that reconciles the two branches. Any project that has previously merged with the skeleton but now gets an error "fatal: refusing to merge unrelated histories" should instead use the handoff branch once to incorporate the new main branch.
+
+```
+$ git pull https://github.com/jaraco/skeleton 2020-handoff
+```
+
+This handoff needs to be pulled just once and thereafter the project can pull from the main head.
+
+The archive and handoff branches from prior collapses are indicate here:
+
+| refresh | archive         | handoff      |
+|---------|-----------------|--------------|
+| 2020-12 | archive/2020-12 | 2020-handoff |
+
 # Features
 
 The features/techniques employed by the skeleton include: