@rozek/nanoclaw 1.2.17

package/.claude/skills/setup/SKILL.md

@@ -0,0 +1,218 @@
+---
+name: setup
+description: Run initial NanoClaw setup. Use when user wants to install dependencies, authenticate messaging channels, register their main channel, or start the background services. Triggers on "setup", "install", "configure nanoclaw", or first-time setup requests.
+---
+
+# NanoClaw Setup
+
+Run setup steps automatically. Only pause when user action is required (channel authentication, configuration choices). Setup uses `bash setup.sh` for bootstrap, then `npx tsx setup/index.ts --step <name>` for all other steps. Steps emit structured status blocks to stdout. Verbose logs go to `logs/setup.log`.
+
+**Principle:** When something is broken or missing, fix it. Don't tell the user to go fix it themselves unless it genuinely requires their manual action (e.g. authenticating a channel, pasting a secret token). If a dependency is missing, install it. If a service won't start, diagnose and repair. Ask the user for permission when needed, then do the work.
+
+**UX Note:** Use `AskUserQuestion` for all user-facing questions.
+
+## 0. Git & Fork Setup
+
+Check the git remote configuration to ensure the user has a fork and upstream is configured.
+
+Run:
+- `git remote -v`
+
+**Case A — `origin` points to `qwibitai/nanoclaw` (user cloned directly):**
+
+The user cloned instead of forking. AskUserQuestion: "You cloned NanoClaw directly. We recommend forking so you can push your customizations. Would you like to set up a fork?"
+- Fork now (recommended) — walk them through it
+- Continue without fork — they'll only have local changes
+
+If fork: instruct the user to fork `qwibitai/nanoclaw` on GitHub (they need to do this in their browser), then ask them for their GitHub username. Run:
+```bash
+git remote rename origin upstream
+git remote add origin https://github.com/<their-username>/nanoclaw.git
+git push --force origin main
+```
+Verify with `git remote -v`.
+
+If continue without fork: add upstream so they can still pull updates:
+```bash
+git remote add upstream https://github.com/qwibitai/nanoclaw.git
+```
+
+**Case B — `origin` points to user's fork, no `upstream` remote:**
+
+Add upstream:
+```bash
+git remote add upstream https://github.com/qwibitai/nanoclaw.git
+```
+
+**Case C — both `origin` (user's fork) and `upstream` (qwibitai) exist:**
+
+Already configured. Continue.
+
+**Verify:** `git remote -v` should show `origin` → user's repo, `upstream` → `qwibitai/nanoclaw.git`.
+
+## 1. Bootstrap (Node.js + Dependencies)
+
+Run `bash setup.sh` and parse the status block.
+
+- If NODE_OK=false → Node.js is missing or too old. Use `AskUserQuestion: Would you like me to install Node.js 22?` If confirmed:
+  - macOS: `brew install node@22` (if brew available) or install nvm then `nvm install 22`
+  - Linux: `curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - && sudo apt-get install -y nodejs`, or nvm
+  - After installing Node, re-run `bash setup.sh`
+- If DEPS_OK=false → Read `logs/setup.log`. Try: delete `node_modules`, re-run `bash setup.sh`. If native module build fails, install build tools (`xcode-select --install` on macOS, `build-essential` on Linux), then retry.
+- If NATIVE_OK=false → better-sqlite3 failed to load. Install build tools and re-run.
+- Record PLATFORM and IS_WSL for later steps.
+
+## 2. Check Environment
+
+Run `npx tsx setup/index.ts --step environment` and parse the status block.
+
+- If HAS_AUTH=true → WhatsApp is already configured, note for step 5
+- If HAS_REGISTERED_GROUPS=true → note existing config, offer to skip or reconfigure
+- Record APPLE_CONTAINER and DOCKER values for step 3
+
+## 3. Container Runtime
+
+### 3a. Choose runtime
+
+Check the preflight results for `APPLE_CONTAINER` and `DOCKER`, and the PLATFORM from step 1.
+
+- PLATFORM=linux → Docker (only option)
+- PLATFORM=macos + APPLE_CONTAINER=installed → Use `AskUserQuestion: Docker (cross-platform) or Apple Container (native macOS)?` If Apple Container, run `/convert-to-apple-container` now, then skip to 3c.
+- PLATFORM=macos + APPLE_CONTAINER=not_found → Docker
+
+### 3a-docker. Install Docker
+
+- DOCKER=running → continue to 4b
+- DOCKER=installed_not_running → start Docker: `open -a Docker` (macOS) or `sudo systemctl start docker` (Linux). Wait 15s, re-check with `docker info`.
+- DOCKER=not_found → Use `AskUserQuestion: Docker is required for running agents. Would you like me to install it?` If confirmed:
+  - macOS: install via `brew install --cask docker`, then `open -a Docker` and wait for it to start. If brew not available, direct to Docker Desktop download at https://docker.com/products/docker-desktop
+  - Linux: install with `curl -fsSL https://get.docker.com | sh && sudo usermod -aG docker $USER`. Note: user may need to log out/in for group membership.
+
+### 3b. Apple Container conversion gate (if needed)
+
+**If the chosen runtime is Apple Container**, you MUST check whether the source code has already been converted from Docker to Apple Container. Do NOT skip this step. Run:
+
+```bash
+grep -q "CONTAINER_RUNTIME_BIN = 'container'" src/container-runtime.ts && echo "ALREADY_CONVERTED" || echo "NEEDS_CONVERSION"
+```
+
+**If NEEDS_CONVERSION**, the source code still uses Docker as the runtime. You MUST run the `/convert-to-apple-container` skill NOW, before proceeding to the build step.
+
+**If ALREADY_CONVERTED**, the code already uses Apple Container. Continue to 3c.
+
+**If the chosen runtime is Docker**, no conversion is needed. Continue to 3c.
+
+### 3c. Build and test
+
+Run `npx tsx setup/index.ts --step container -- --runtime <chosen>` and parse the status block.
+
+**If BUILD_OK=false:** Read `logs/setup.log` tail for the build error.
+- Cache issue (stale layers): `docker builder prune -f` (Docker) or `container builder stop && container builder rm && container builder start` (Apple Container). Retry.
+- Dockerfile syntax or missing files: diagnose from the log and fix, then retry.
+
+**If TEST_OK=false but BUILD_OK=true:** The image built but won't run. Check logs — common cause is runtime not fully started. Wait a moment and retry the test.
+
+## 4. Claude Authentication (No Script)
+
+If HAS_ENV=true from step 2, read `.env` and check for `CLAUDE_CODE_OAUTH_TOKEN` or `ANTHROPIC_API_KEY`. If present, confirm with user: keep or reconfigure?
+
+AskUserQuestion: Claude subscription (Pro/Max) vs Anthropic API key?
+
+**Subscription:** Tell user to run `claude setup-token` in another terminal, copy the token, add `CLAUDE_CODE_OAUTH_TOKEN=<token>` to `.env`. Do NOT collect the token in chat.
+
+**API key:** Tell user to add `ANTHROPIC_API_KEY=<key>` to `.env`.
+
+## 5. Set Up Channels
+
+AskUserQuestion (multiSelect): Which messaging channels do you want to enable?
+- WhatsApp (authenticates via QR code or pairing code)
+- Telegram (authenticates via bot token from @BotFather)
+- Slack (authenticates via Slack app with Socket Mode)
+- Discord (authenticates via Discord bot token)
+
+**Delegate to each selected channel's own skill.** Each channel skill handles its own code installation, authentication, registration, and JID resolution. This avoids duplicating channel-specific logic and ensures JIDs are always correct.
+
+For each selected channel, invoke its skill:
+
+- **WhatsApp:** Invoke `/add-whatsapp`
+- **Telegram:** Invoke `/add-telegram`
+- **Slack:** Invoke `/add-slack`
+- **Discord:** Invoke `/add-discord`
+
+Each skill will:
+1. Install the channel code (via `git merge` of the skill branch)
+2. Collect credentials/tokens and write to `.env`
+3. Authenticate (WhatsApp QR/pairing, or verify token-based connection)
+4. Register the chat with the correct JID format
+5. Build and verify
+
+**After all channel skills complete**, install dependencies and rebuild — channel merges may introduce new packages:
+
+```bash
+npm install && npm run build
+```
+
+If the build fails, read the error output and fix it (usually a missing dependency). Then continue to step 6.
+
+## 6. Mount Allowlist
+
+AskUserQuestion: Agent access to external directories?
+
+**No:** `npx tsx setup/index.ts --step mounts -- --empty`
+**Yes:** Collect paths/permissions. `npx tsx setup/index.ts --step mounts -- --json '{"allowedRoots":[...],"blockedPatterns":[],"nonMainReadOnly":true}'`
+
+## 7. Start Service
+
+If service already running: unload first.
+- macOS: `launchctl unload ~/Library/LaunchAgents/com.nanoclaw.plist`
+- Linux: `systemctl --user stop nanoclaw` (or `systemctl stop nanoclaw` if root)
+
+Run `npx tsx setup/index.ts --step service` and parse the status block.
+
+**If FALLBACK=wsl_no_systemd:** WSL without systemd detected. Tell user they can either enable systemd in WSL (`echo -e "[boot]\nsystemd=true" | sudo tee /etc/wsl.conf` then restart WSL) or use the generated `start-nanoclaw.sh` wrapper.
+
+**If DOCKER_GROUP_STALE=true:** The user was added to the docker group after their session started — the systemd service can't reach the Docker socket. Ask user to run these two commands:
+
+1. Immediate fix: `sudo setfacl -m u:$(whoami):rw /var/run/docker.sock`
+2. Persistent fix (re-applies after every Docker restart):
+```bash
+sudo mkdir -p /etc/systemd/system/docker.service.d
+sudo tee /etc/systemd/system/docker.service.d/socket-acl.conf << 'EOF'
+[Service]
+ExecStartPost=/usr/bin/setfacl -m u:USERNAME:rw /var/run/docker.sock
+EOF
+sudo systemctl daemon-reload
+```
+Replace `USERNAME` with the actual username (from `whoami`). Run the two `sudo` commands separately — the `tee` heredoc first, then `daemon-reload`. After user confirms setfacl ran, re-run the service step.
+
+**If SERVICE_LOADED=false:**
+- Read `logs/setup.log` for the error.
+- macOS: check `launchctl list | grep nanoclaw`. If PID=`-` and status non-zero, read `logs/nanoclaw.error.log`.
+- Linux: check `systemctl --user status nanoclaw`.
+- Re-run the service step after fixing.
+
+## 8. Verify
+
+Run `npx tsx setup/index.ts --step verify` and parse the status block.
+
+**If STATUS=failed, fix each:**
+- SERVICE=stopped → `npm run build`, then restart: `launchctl kickstart -k gui/$(id -u)/com.nanoclaw` (macOS) or `systemctl --user restart nanoclaw` (Linux) or `bash start-nanoclaw.sh` (WSL nohup)
+- SERVICE=not_found → re-run step 7
+- CREDENTIALS=missing → re-run step 4
+- CHANNEL_AUTH shows `not_found` for any channel → re-invoke that channel's skill (e.g. `/add-telegram`)
+- REGISTERED_GROUPS=0 → re-invoke the channel skills from step 5
+- MOUNT_ALLOWLIST=missing → `npx tsx setup/index.ts --step mounts -- --empty`
+
+Tell user to test: send a message in their registered chat. Show: `tail -f logs/nanoclaw.log`
+
+## Troubleshooting
+
+**Service not starting:** Check `logs/nanoclaw.error.log`. Common: wrong Node path (re-run step 7), missing `.env` (step 4), missing channel credentials (re-invoke channel skill).
+
+**Container agent fails ("Claude Code process exited with code 1"):** Ensure the container runtime is running — `open -a Docker` (macOS Docker), `container system start` (Apple Container), or `sudo systemctl start docker` (Linux). Check container logs in `groups/main/logs/container-*.log`.
+
+**No response to messages:** Check trigger pattern. Main channel doesn't need prefix. Check DB: `npx tsx setup/index.ts --step verify`. Check `logs/nanoclaw.log`.
+
+**Channel not connecting:** Verify the channel's credentials are set in `.env`. Channels auto-enable when their credentials are present. For WhatsApp: check `store/auth/creds.json` exists. For token-based channels: check token values in `.env`. Restart the service after any `.env` change.
+
+**Unload service:** macOS: `launchctl unload ~/Library/LaunchAgents/com.nanoclaw.plist` | Linux: `systemctl --user stop nanoclaw`

package/.claude/skills/update-nanoclaw/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: update-nanoclaw
+description: Efficiently bring upstream NanoClaw updates into a customized install, with preview, selective cherry-pick, and low token usage.
+---
+
+# About
+
+Your NanoClaw fork drifts from upstream as you customize it. This skill pulls upstream changes into your install without losing your modifications.
+
+Run `/update-nanoclaw` in Claude Code.
+
+## How it works
+
+**Preflight**: checks for clean working tree (`git status --porcelain`). If `upstream` remote is missing, asks you for the URL (defaults to `https://github.com/qwibitai/nanoclaw.git`) and adds it. Detects the upstream branch name (`main` or `master`).
+
+**Backup**: creates a timestamped backup branch and tag (`backup/pre-update-<hash>-<timestamp>`, `pre-update-<hash>-<timestamp>`) before touching anything. Safe to run multiple times.
+
+**Preview**: runs `git log` and `git diff` against the merge base to show upstream changes since your last sync. Groups changed files into categories:
+- **Skills** (`.claude/skills/`): unlikely to conflict unless you edited an upstream skill
+- **Source** (`src/`): may conflict if you modified the same files
+- **Build/config** (`package.json`, `tsconfig*.json`, `container/`): review needed
+
+**Update paths** (you pick one):
+- `merge` (default): `git merge upstream/<branch>`. Resolves all conflicts in one pass.
+- `cherry-pick`: `git cherry-pick <hashes>`. Pull in only the commits you want.
+- `rebase`: `git rebase upstream/<branch>`. Linear history, but conflicts resolve per-commit.
+- `abort`: just view the changelog, change nothing.
+
+**Conflict preview**: before merging, runs a dry-run (`git merge --no-commit --no-ff`) to show which files would conflict. You can still abort at this point.
+
+**Conflict resolution**: opens only conflicted files, resolves the conflict markers, keeps your local customizations intact.
+
+**Validation**: runs `npm run build` and `npm test`.
+
+**Breaking changes check**: after validation, reads CHANGELOG.md for any `[BREAKING]` entries introduced by the update. If found, shows each breaking change and offers to run the recommended skill to migrate.
+
+## Rollback
+
+The backup tag is printed at the end of each run:
+```
+git reset --hard pre-update-<hash>-<timestamp>
+```
+
+Backup branch `backup/pre-update-<hash>-<timestamp>` also exists.
+
+## Token usage
+
+Only opens files with actual conflicts. Uses `git log`, `git diff`, and `git status` for everything else. Does not scan or refactor unrelated code.
+
+---
+
+# Goal
+Help a user with a customized NanoClaw install safely incorporate upstream changes without a fresh reinstall and without blowing tokens.
+
+# Operating principles
+- Never proceed with a dirty working tree.
+- Always create a rollback point (backup branch + tag) before touching anything.
+- Prefer git-native operations (fetch, merge, cherry-pick). Do not manually rewrite files except conflict markers.
+- Default to MERGE (one-pass conflict resolution). Offer REBASE as an explicit option.
+- Keep token usage low: rely on `git status`, `git log`, `git diff`, and open only conflicted files.
+
+# Step 0: Preflight (stop early if unsafe)
+Run:
+- `git status --porcelain`
+If output is non-empty:
+- Tell the user to commit or stash first, then stop.
+
+Confirm remotes:
+- `git remote -v`
+If `upstream` is missing:
+- Ask the user for the upstream repo URL (default: `https://github.com/qwibitai/nanoclaw.git`).
+- Add it: `git remote add upstream <user-provided-url>`
+- Then: `git fetch upstream --prune`
+
+Determine the upstream branch name:
+- `git branch -r | grep upstream/`
+- If `upstream/main` exists, use `main`.
+- If only `upstream/master` exists, use `master`.
+- Otherwise, ask the user which branch to use.
+- Store this as UPSTREAM_BRANCH for all subsequent commands. Every command below that references `upstream/main` should use `upstream/$UPSTREAM_BRANCH` instead.
+
+Fetch:
+- `git fetch upstream --prune`
+
+# Step 1: Create a safety net
+Capture current state:
+- `HASH=$(git rev-parse --short HEAD)`
+- `TIMESTAMP=$(date +%Y%m%d-%H%M%S)`
+
+Create backup branch and tag (using timestamp to avoid collisions on retry):
+- `git branch backup/pre-update-$HASH-$TIMESTAMP`
+- `git tag pre-update-$HASH-$TIMESTAMP`
+
+Save the tag name for later reference in the summary and rollback instructions.
+
+# Step 2: Preview what upstream changed (no edits yet)
+Compute common base:
+- `BASE=$(git merge-base HEAD upstream/$UPSTREAM_BRANCH)`
+
+Show upstream commits since BASE:
+- `git log --oneline $BASE..upstream/$UPSTREAM_BRANCH`
+
+Show local commits since BASE (custom drift):
+- `git log --oneline $BASE..HEAD`
+
+Show file-level impact from upstream:
+- `git diff --name-only $BASE..upstream/$UPSTREAM_BRANCH`
+
+Bucket the upstream changed files:
+- **Skills** (`.claude/skills/`): unlikely to conflict unless the user edited an upstream skill
+- **Source** (`src/`): may conflict if user modified the same files
+- **Build/config** (`package.json`, `package-lock.json`, `tsconfig*.json`, `container/`, `launchd/`): review needed
+- **Other**: docs, tests, misc
+
+Present these buckets to the user and ask them to choose one path using AskUserQuestion:
+- A) **Full update**: merge all upstream changes
+- B) **Selective update**: cherry-pick specific upstream commits
+- C) **Abort**: they only wanted the preview
+- D) **Rebase mode**: advanced, linear history (warn: resolves conflicts per-commit)
+
+If Abort: stop here.
+
+# Step 3: Conflict preview (before committing anything)
+If Full update or Rebase:
+- Dry-run merge to preview conflicts. Run these as a single chained command so the abort always executes:
+  ```
+  git merge --no-commit --no-ff upstream/$UPSTREAM_BRANCH; git diff --name-only --diff-filter=U; git merge --abort
+  ```
+- If conflicts were listed: show them and ask user if they want to proceed.
+- If no conflicts: tell user it is clean and proceed.
+
+# Step 4A: Full update (MERGE, default)
+Run:
+- `git merge upstream/$UPSTREAM_BRANCH --no-edit`
+
+If conflicts occur:
+- Run `git status` and identify conflicted files.
+- For each conflicted file:
+  - Open the file.
+  - Resolve only conflict markers.
+  - Preserve intentional local customizations.
+  - Incorporate upstream fixes/improvements.
+  - Do not refactor surrounding code.
+  - `git add <file>`
+- When all resolved:
+  - If merge did not auto-commit: `git commit --no-edit`
+
+# Step 4B: Selective update (CHERRY-PICK)
+If user chose Selective:
+- Recompute BASE if needed: `BASE=$(git merge-base HEAD upstream/$UPSTREAM_BRANCH)`
+- Show commit list again: `git log --oneline $BASE..upstream/$UPSTREAM_BRANCH`
+- Ask user which commit hashes they want.
+- Apply: `git cherry-pick <hash1> <hash2> ...`
+
+If conflicts during cherry-pick:
+- Resolve only conflict markers, then:
+  - `git add <file>`
+  - `git cherry-pick --continue`
+If user wants to stop:
+  - `git cherry-pick --abort`
+
+# Step 4C: Rebase (only if user explicitly chose option D)
+Run:
+- `git rebase upstream/$UPSTREAM_BRANCH`
+
+If conflicts:
+- Resolve conflict markers only, then:
+  - `git add <file>`
+  - `git rebase --continue`
+If it gets messy (more than 3 rounds of conflicts):
+  - `git rebase --abort`
+  - Recommend merge instead.
+
+# Step 5: Validation
+Run:
+- `npm run build`
+- `npm test` (do not fail the flow if tests are not configured)
+
+If build fails:
+- Show the error.
+- Only fix issues clearly caused by the merge (missing imports, type mismatches from merged code).
+- Do not refactor unrelated code.
+- If unclear, ask the user before making changes.
+
+# Step 6: Breaking changes check
+After validation succeeds, check if the update introduced any breaking changes.
+
+Determine which CHANGELOG entries are new by diffing against the backup tag:
+- `git diff <backup-tag-from-step-1>..HEAD -- CHANGELOG.md`
+
+Parse the diff output for lines starting with `+[BREAKING]`. Each such line is one breaking change entry. The format is:
+```
+[BREAKING] <description>. Run `/<skill-name>` to <action>.
+```
+
+If no `[BREAKING]` lines are found:
+- Skip this step silently. Proceed to Step 7 (skill updates check).
+
+If one or more `[BREAKING]` lines are found:
+- Display a warning header to the user: "This update includes breaking changes that may require action:"
+- For each breaking change, display the full description.
+- Collect all skill names referenced in the breaking change entries (the `/<skill-name>` part).
+- Use AskUserQuestion to ask the user which migration skills they want to run now. Options:
+  - One option per referenced skill (e.g., "Run /add-whatsapp to re-add WhatsApp channel")
+  - "Skip — I'll handle these manually"
+- Set `multiSelect: true` so the user can pick multiple skills if there are several breaking changes.
+- For each skill the user selects, invoke it using the Skill tool.
+- After all selected skills complete (or if user chose Skip), proceed to Step 7 (skill updates check).
+
+# Step 7: Check for skill updates
+After the summary, check if skills are distributed as branches in this repo:
+- `git branch -r --list 'upstream/skill/*'`
+
+If any `upstream/skill/*` branches exist:
+- Use AskUserQuestion to ask: "Upstream has skill branches. Would you like to check for skill updates?"
+  - Option 1: "Yes, check for updates" (description: "Runs /update-skills to check for and apply skill branch updates")
+  - Option 2: "No, skip" (description: "You can run /update-skills later any time")
+- If user selects yes, invoke `/update-skills` using the Skill tool.
+- After the skill completes (or if user selected no), proceed to Step 8.
+
+# Step 8: Summary + rollback instructions
+Show:
+- Backup tag: the tag name created in Step 1
+- New HEAD: `git rev-parse --short HEAD`
+- Upstream HEAD: `git rev-parse --short upstream/$UPSTREAM_BRANCH`
+- Conflicts resolved (list files, if any)
+- Breaking changes applied (list skills run, if any)
+- Remaining local diff vs upstream: `git diff --name-only upstream/$UPSTREAM_BRANCH..HEAD`
+
+Tell the user:
+- To rollback: `git reset --hard <backup-tag-from-step-1>`
+- Backup branch also exists: `backup/pre-update-<HASH>-<TIMESTAMP>`
+- Restart the service to apply changes:
+  - If using launchd: `launchctl unload ~/Library/LaunchAgents/com.nanoclaw.plist && launchctl load ~/Library/LaunchAgents/com.nanoclaw.plist`
+  - If running manually: restart `npm run dev`

package/.claude/skills/update-skills/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: update-skills
+description: Check for and apply updates to installed skill branches from upstream.
+---
+
+# About
+
+Skills are distributed as git branches (`skill/*`). When you install a skill, you merge its branch into your repo. This skill checks upstream for newer commits on those skill branches and helps you update.
+
+Run `/update-skills` in Claude Code.
+
+## How it works
+
+**Preflight**: checks for clean working tree and upstream remote.
+
+**Detection**: fetches upstream, lists all `upstream/skill/*` branches, determines which ones you've previously merged (via merge-base), and checks if any have new commits.
+
+**Selection**: presents a list of skills with available updates. You pick which to update.
+
+**Update**: merges each selected skill branch, resolves conflicts if any, then validates with build + test.
+
+---
+
+# Goal
+Help users update their installed skill branches from upstream without losing local customizations.
+
+# Operating principles
+- Never proceed with a dirty working tree.
+- Only offer updates for skills the user has already merged (installed).
+- Use git-native operations. Do not manually rewrite files except conflict markers.
+- Keep token usage low: rely on `git` commands, only open files with actual conflicts.
+
+# Step 0: Preflight
+
+Run:
+- `git status --porcelain`
+
+If output is non-empty:
+- Tell the user to commit or stash first, then stop.
+
+Check remotes:
+- `git remote -v`
+
+If `upstream` is missing:
+- Ask the user for the upstream repo URL (default: `https://github.com/qwibitai/nanoclaw.git`).
+- `git remote add upstream <url>`
+
+Fetch:
+- `git fetch upstream --prune`
+
+# Step 1: Detect installed skills with available updates
+
+List all upstream skill branches:
+- `git branch -r --list 'upstream/skill/*'`
+
+For each `upstream/skill/<name>`:
+1. Check if the user has merged this skill branch before:
+   - `git merge-base --is-ancestor upstream/skill/<name>~1 HEAD` — if this succeeds (exit 0) for any ancestor commit of the skill branch, the user has merged it at some point. A simpler check: `git log --oneline --merges --grep="skill/<name>" HEAD` to see if there's a merge commit referencing this branch.
+   - Alternative: `MERGE_BASE=$(git merge-base HEAD upstream/skill/<name>)` — if the merge base is NOT the initial commit and the merge base includes commits unique to the skill branch, it has been merged.
+   - Simplest reliable check: compare `git merge-base HEAD upstream/skill/<name>` with `git merge-base HEAD upstream/main`. If the skill merge-base is strictly ahead of (or different from) the main merge-base, the user has merged this skill.
+2. Check if there are new commits on the skill branch not yet in HEAD:
+   - `git log --oneline HEAD..upstream/skill/<name>`
+   - If this produces output, there are updates available.
+
+Build three lists:
+- **Updates available**: skills that are merged AND have new commits
+- **Up to date**: skills that are merged and have no new commits
+- **Not installed**: skills that have never been merged
+
+# Step 2: Present results
+
+If no skills have updates available:
+- Tell the user all installed skills are up to date. List them.
+- If there are uninstalled skills, mention them briefly (e.g., "3 other skills available in upstream that you haven't installed").
+- Stop here.
+
+If updates are available:
+- Show the list of skills with updates, including the number of new commits for each:
+  ```
+  skill/<name>: 3 new commits
+  skill/<other>: 1 new commit
+  ```
+- Also show skills that are up to date (for context).
+- Use AskUserQuestion with `multiSelect: true` to let the user pick which skills to update.
+  - One option per skill with updates, labeled with the skill name and commit count.
+  - Add an option: "Skip — don't update any skills now"
+- If user selects Skip, stop here.
+
+# Step 3: Apply updates
+
+For each selected skill (process one at a time):
+
+1. Tell the user which skill is being updated.
+2. Run: `git merge upstream/skill/<name> --no-edit`
+3. If the merge is clean, move to the next skill.
+4. If conflicts occur:
+   - Run `git status` to identify conflicted files.
+   - For each conflicted file:
+     - Open the file.
+     - Resolve only conflict markers.
+     - Preserve intentional local customizations.
+     - `git add <file>`
+   - Complete the merge: `git commit --no-edit`
+
+If a merge fails badly (e.g., cannot resolve conflicts):
+- `git merge --abort`
+- Tell the user this skill could not be auto-updated and they should resolve it manually.
+- Continue with the remaining skills.
+
+# Step 4: Validation
+
+After all selected skills are merged:
+- `npm run build`
+- `npm test` (do not fail the flow if tests are not configured)
+
+If build fails:
+- Show the error.
+- Only fix issues clearly caused by the merge (missing imports, type mismatches).
+- Do not refactor unrelated code.
+- If unclear, ask the user.
+
+# Step 5: Summary
+
+Show:
+- Skills updated (list)
+- Skills skipped or failed (if any)
+- New HEAD: `git rev-parse --short HEAD`
+- Any conflicts that were resolved (list files)
+
+If the service is running, remind the user to restart it to pick up changes.