| name | update-from-public |
| description | Pull upstream updates into private NanoClaw. The chain is qwibitai → public → private. This skill handles both pulling qwibitai changes into public and then merging public into private. Use when upstream has new features, when the user asks to update, or when /update-nanoclaw is invoked. |
Update from Upstream
Pull updates through the chain: qwibitai/nanoclaw → jbaruch/nanoclaw-public → jbaruch/nanoclaw (private).
Overview: Three steps — (1) sync public repo from qwibitai, (2) merge public into private, (3) deploy to NAS. Check the "When NOT to update" section before starting.
Step 1: Update public from qwibitai
cd ~/Projects/nanoclaw-public
git fetch origin
git checkout main
git pull origin main
git remote get-url qwibitai 2>/dev/null || git remote add qwibitai https://github.com/qwibitai/nanoclaw.git
git fetch qwibitai
git diff --stat qwibitai/main
git merge qwibitai/main
git log --oneline -3
git push origin main
Step 2: Update private from public
cd ~/Projects/nanoclaw
git fetch upstream
git diff --stat upstream/main
git merge upstream/main
git log --oneline -3
git push origin main
Step 3: Deploy to NAS
ssh nas "cd ~/nanoclaw && ./scripts/deploy.sh"
Or if only tiles changed:
ssh nas "cd ~/nanoclaw && ./scripts/deploy.sh --tiles-only"
After deploying, verify the deployment succeeded:
ssh nas "cd ~/nanoclaw && ./scripts/deploy.sh --health-check"
When NOT to update
- If private has uncommitted work — commit or stash first
- If AyeAye is mid-task — nuke the container first, update, then let it respawn
- If upstream has breaking changes — read the changelog first, test locally
Conflict strategy
Private always has more code than public (private integrations). When merging:
- Upstream changed a file we also changed: read both changes, merge manually
- Upstream added a file: accept it (new feature)
- Upstream deleted a file we modified: check if our modifications are still needed
- Our private additions conflict: keep ours, they're intentionally not in upstream