Show sibling projects' versions, and let version update them

A sibling's version is its latest git tag (v1.4.0, or v1.4.0+3 for commits
after it), or, without tags, its commit's date and short hash, like
CoreDesktop's own. The version shown as available is that of the newest
commit on the default branch, which is what update installs.

sibling list shows each sibling's version. sibling check fetches every
sibling at once and shows which have a newer version, and sibling update
[name...] updates the named siblings or all of them. 71-siblings.sh now
runs sibling update, so update and version share one way of updating.

version lists the installed siblings with any newer version and, when run
in a terminal, asks for each one whether to update it now. version --check
and the update notification still only look at CoreDesktop.

The sibling skill docs describe how to release a version by tagging it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

skills/sibling-project-format.md

@@ -35,7 +35,8 @@ approach or the other, not both, or the project updates twice.
 ### `update`
 
 CoreDesktop runs its own update hooks in order (`10-pacman.sh` … `70-claude.sh`).
-Next, `updates.d/71-siblings.sh` takes each sibling in alphabetical order and:
+Next, `updates.d/71-siblings.sh` runs `sibling update`, which takes each
+sibling in alphabetical order and:
 
 1. Runs `git pull --ff-only --quiet` in its folder.
 2. If the pull succeeded and `update.sh` exists, runs `bash update.sh` with the
@@ -46,6 +47,12 @@ A failed pull or a non-zero exit from `update.sh` is printed and listed in
 CoreDesktop's end-of-run hooks (GNOME settings, firmware, cleanup, reboot
 check) run after all siblings.
 
+### `sibling update [name...]`
+
+Pulls and runs `update.sh` for the named siblings, or for all of them, exactly
+as `update` does, and prints each one's new version. `version` uses it when
+the user agrees to update a sibling that has a newer version.
+
 ### `sibling remove <name>`
 
 This only deletes `~/.local/share/siblings/<name>`. CoreDesktop has no uninstall
@@ -122,6 +129,28 @@ step for siblings, so anything `install.sh` set up elsewhere stays.
   caches and per-machine state outside the repo (e.g. `~/.config/<name>/`), or
   into paths listed in `.gitignore`.
 
+### Versions
+
+CoreDesktop shows a sibling's version in `sibling list`, `sibling check` and
+`version`, and works it out from git, so there is no version file to keep:
+
+- **With tags:** the latest tag reachable from the commit, e.g. `v1.4.0`, or
+  `v1.4.0+3` three commits after it. To release a version, tag the commit on
+  the default branch and push the tag:
+  ```bash
+  git tag v1.5.0 && git push origin v1.5.0
+  ```
+- **Without tags:** the commit's date and short hash, e.g.
+  `2026.11.02 (a1b2c3d)`, the way CoreDesktop versions itself.
+
+`update` always installs the newest commit on the default branch, tagged or
+not. So the version offered as available is that commit's (`v1.4.0+5` if
+nothing since `v1.4.0` has been tagged). Tag a version when it's ready, rather
+than holding commits back for a release.
+
+Annotated and lightweight tags both work, but never move or delete a pushed
+tag: the user's clone keeps the old one.
+
 ### Authentication
 
 `sibling` clones with plain `git`. A private repo works only if the user can
@@ -191,9 +220,10 @@ ln -s /path/to/real/coredesktop "$HOME/.local/share/coredesktop"
 # Install
 bash "$HOME/.local/share/coredesktop/sibling" add /path/to/sibling-repo
 
-# Commit a change in /path/to/sibling-repo, then run the update hook the way
-# `update` does
-( source "$HOME/.local/share/coredesktop/updates.d/71-siblings.sh"; is_installed && run_update )
+# Commit a change in /path/to/sibling-repo, check that it's seen as newer,
+# then update the way `update` does
+bash "$HOME/.local/share/coredesktop/sibling" check
+bash "$HOME/.local/share/coredesktop/sibling" update
 
 # Re-run the install to check it is safe to repeat
 bash "$HOME/.local/share/coredesktop/sibling" add /path/to/sibling-repo
@@ -214,6 +244,8 @@ changing.
       `COREDESKTOP="$HOME/.local/share/coredesktop"` themselves
 - [ ] Nothing writes to tracked files in the clone, and the default branch is
       never force-pushed
+- [ ] Releases are tagged on the default branch (optional; without tags the
+      version is the commit's date and hash), and pushed tags are never moved
 - [ ] The project doesn't also copy a hook into CoreDesktop's `updates.d/`
 - [ ] The README tells users to install with
       `sibling add <url>`

skills/sibling-project-updates.md

@@ -32,7 +32,9 @@ Commands:
 ```bash
 sibling                 # asks for the git URL
 sibling add <url>       # same, without the prompt
-sibling list            # installed siblings, their URL and current commit
+sibling list            # installed siblings, their version and URL
+sibling check           # which siblings have a newer version
+sibling update [name]   # update the named siblings, or all of them
 sibling remove <name>   # deletes ~/.local/share/siblings/<name>
 ```