[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69A5SEJ762VPRDBCAPD9Y7K":3,"skill-same:01M69A5SEJ762VPRDBCAPD9Y7K":54},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":20,"linkOnly":21,"markdownContent":22,"markdownBody":23,"frontMatter":24,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M69A5SEJ762VPRDBCAPD9Y7K","update-nanoclaw",null,"Efficiently bring upstream NanoClaw updates into a customized install, with preview, selective cherry-pick, and low token usage.","microsoft\u002Famplifier-app-nanoclaw","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69A31J3GTKVZDZZVPRQWWR5",5,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fupdate-nanoclaw\u002FSKILL.md",[],[19],"update nanoclaw","2026-11-10 10:12:30",false,"---\nname: update-nanoclaw\ndescription: Efficiently bring upstream NanoClaw updates into a customized install, with preview, selective cherry-pick, and low token usage.\n---\n\n# About\n\nYour NanoClaw fork drifts from upstream as you customize it. This skill pulls upstream changes into your install without losing your modifications.\n\nRun `\u002Fupdate-nanoclaw` in Claude Code.\n\n## How it works\n\n**Preflight**: checks for clean working tree (`git status --porcelain`). If `upstream` remote is missing, asks you for the URL (defaults to `https:\u002F\u002Fgithub.com\u002Fnanocoai\u002Fnanoclaw.git`) and adds it. Detects the upstream branch name (`main` or `master`).\n\n**Backup**: creates a timestamped backup branch and tag (`backup\u002Fpre-update-\u003Chash>-\u003Ctimestamp>`, `pre-update-\u003Chash>-\u003Ctimestamp>`) before touching anything. Safe to run multiple times.\n\n**Preview**: runs `git log` and `git diff` against the merge base to show upstream changes since your last sync. Groups changed files into categories:\n- **Skills** (`.claude\u002Fskills\u002F`): unlikely to conflict unless you edited an upstream skill\n- **Host source** (`src\u002F`): may conflict if you modified the same files\n- **Container** (`container\u002F`): triggers container rebuild\n- **Build\u002Fconfig** (`package.json`, `pnpm-lock.yaml`, `tsconfig*.json`): lockfile changes trigger dep install\n\n**Update paths** (you pick one):\n- `merge` (default): `git merge upstream\u002F\u003Cbranch>`. Resolves all conflicts in one pass.\n- `cherry-pick`: `git cherry-pick \u003Chashes>`. Pull in only the commits you want.\n- `rebase`: `git rebase upstream\u002F\u003Cbranch>`. Linear history, but conflicts resolve per-commit.\n- `abort`: just view the changelog, change nothing.\n\n**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.\n\n**Conflict resolution**: opens only conflicted files, resolves the conflict markers, keeps your local customizations intact.\n\n**Validation**: runs `pnpm run build` and `pnpm test`. If container files changed, also runs the container typecheck and `.\u002Fcontainer\u002Fbuild.sh`.\n\n**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.\n\n## Rollback\n\nThe backup tag is printed at the end of each run:\n```\ngit reset --hard pre-update-\u003Chash>-\u003Ctimestamp>\n```\n\nBackup branch `backup\u002Fpre-update-\u003Chash>-\u003Ctimestamp>` also exists.\n\n## Token usage\n\nOnly opens files with actual conflicts. Uses `git log`, `git diff`, and `git status` for everything else. Does not scan or refactor unrelated code.\n\n---\n\n# Goal\nHelp a user with a customized NanoClaw install safely incorporate upstream changes without a fresh reinstall and without blowing tokens.\n\n# Operating principles\n- Never proceed with a dirty working tree.\n- Always create a rollback point (backup branch + tag) before touching anything.\n- Prefer git-native operations (fetch, merge, cherry-pick). Do not manually rewrite files except conflict markers.\n- Default to MERGE (one-pass conflict resolution). Offer REBASE as an explicit option.\n- Keep token usage low: rely on `git status`, `git log`, `git diff`, and open only conflicted files.\n\n# Step 0: Preflight (stop early if unsafe)\nRun:\n- `git status --porcelain`\nIf output is non-empty:\n- Tell the user to commit or stash first, then stop.\n\nConfirm remotes:\n- `git remote -v`\nIf `upstream` is missing:\n- Ask the user for the upstream repo URL (default: `https:\u002F\u002Fgithub.com\u002Fnanocoai\u002Fnanoclaw.git`).\n- Add it: `git remote add upstream \u003Cuser-provided-url>`\n- Then: `git fetch upstream --prune`\n\nDetermine the upstream branch name:\n- `git branch -r | grep upstream\u002F`\n- If `upstream\u002Fmain` exists, use `main`.\n- If only `upstream\u002Fmaster` exists, use `master`.\n- Otherwise, ask the user which branch to use.\n- Store this as UPSTREAM_BRANCH for all subsequent commands. Every command below that references `upstream\u002Fmain` should use `upstream\u002F$UPSTREAM_BRANCH` instead.\n\nFetch:\n- `git fetch upstream --prune`\n\n# Step 1: Create a safety net\nCapture current state:\n- `HASH=$(git rev-parse --short HEAD)`\n- `TIMESTAMP=$(date +%Y%m%d-%H%M%S)`\n\nCreate backup branch and tag (using timestamp to avoid collisions on retry):\n- `git branch backup\u002Fpre-update-$HASH-$TIMESTAMP`\n- `git tag pre-update-$HASH-$TIMESTAMP`\n\nSave the tag name for later reference in the summary and rollback instructions.\n\n# Step 2: Preview what upstream changed (no edits yet)\nCompute common base:\n- `BASE=$(git merge-base HEAD upstream\u002F$UPSTREAM_BRANCH)`\n\nShow upstream commits since BASE:\n- `git log --oneline $BASE..upstream\u002F$UPSTREAM_BRANCH`\n\nShow local commits since BASE (custom drift):\n- `git log --oneline $BASE..HEAD`\n\nShow file-level impact from upstream:\n- `git diff --name-only $BASE..upstream\u002F$UPSTREAM_BRANCH`\n\nBucket the upstream changed files:\n- **Skills** (`.claude\u002Fskills\u002F`): unlikely to conflict unless the user edited an upstream skill\n- **Host source** (`src\u002F`): may conflict if user modified the same files\n- **Container** (`container\u002F`): triggers container rebuild (+ typecheck if `agent-runner\u002Fsrc\u002F` changed)\n- **Build\u002Fconfig** (`package.json`, `pnpm-lock.yaml`, `tsconfig*.json`): lockfile changes trigger dep install\n- **Other**: docs, tests, setup scripts, misc\n\n**Large drift check:** If the upstream commit count and age suggest the user has a lot of catching up to do, mention that `\u002Fmigrate-nanoclaw` might be a better fit — it extracts customizations and reapplies them on clean upstream instead of merging. Offer it as an option but don't push.\n\nPresent these buckets to the user and ask them to choose one path using AskUserQuestion:\n- A) **Full update**: merge all upstream changes\n- B) **Selective update**: cherry-pick specific upstream commits\n- C) **Abort**: they only wanted the preview\n- D) **Rebase mode**: advanced, linear history (warn: resolves conflicts per-commit)\n\nIf Abort: stop here.\n\n# Step 3: Conflict preview (before committing anything)\nIf Full update or Rebase:\n- Dry-run merge to preview conflicts. Run these as a single chained command so the abort always executes:\n  ```\n  git merge --no-commit --no-ff upstream\u002F$UPSTREAM_BRANCH; git diff --name-only --diff-filter=U; git merge --abort\n  ```\n- If conflicts were listed: show them and ask user if they want to proceed.\n- If no conflicts: tell user it is clean and proceed.\n\n# Step 4A: Full update (MERGE, default)\nRun:\n- `git merge upstream\u002F$UPSTREAM_BRANCH --no-edit`\n\nIf conflicts occur:\n- Run `git status` and identify conflicted files.\n- For each conflicted file:\n  - Open the file.\n  - Resolve only conflict markers.\n  - Preserve intentional local customizations.\n  - Incorporate upstream fixes\u002Fimprovements.\n  - Do not refactor surrounding code.\n  - `git add \u003Cfile>`\n- When all resolved:\n  - If merge did not auto-commit: `git commit --no-edit`\n\n# Step 4B: Selective update (CHERRY-PICK)\nIf user chose Selective:\n- Recompute BASE if needed: `BASE=$(git merge-base HEAD upstream\u002F$UPSTREAM_BRANCH)`\n- Show commit list again: `git log --oneline $BASE..upstream\u002F$UPSTREAM_BRANCH`\n- Ask user which commit hashes they want.\n- Apply: `git cherry-pick \u003Chash1> \u003Chash2> ...`\n\nIf conflicts during cherry-pick:\n- Resolve only conflict markers, then:\n  - `git add \u003Cfile>`\n  - `git cherry-pick --continue`\nIf user wants to stop:\n  - `git cherry-pick --abort`\n\n# Step 4C: Rebase (only if user explicitly chose option D)\nRun:\n- `git rebase upstream\u002F$UPSTREAM_BRANCH`\n\nIf conflicts:\n- Resolve conflict markers only, then:\n  - `git add \u003Cfile>`\n  - `git rebase --continue`\nIf it gets messy (more than 3 rounds of conflicts):\n  - `git rebase --abort`\n  - Recommend merge instead.\n\n# Step 4.5: Install dependencies (if lockfiles changed)\nCheck if the merge changed any lockfiles or package manifests:\n- `git diff \u003Cbackup-tag-from-step-1>..HEAD --name-only | grep -E '^(pnpm-lock\\.yaml|package\\.json)$'`\n  - If matched: `pnpm install`\n- `git diff \u003Cbackup-tag-from-step-1>..HEAD --name-only | grep -E '^container\u002Fagent-runner\u002F(bun\\.lock|package\\.json)$'`\n  - If matched AND `command -v bun` succeeds: `cd container\u002Fagent-runner && bun install`\n  - If bun is not installed on the host, skip — container deps will be installed during `.\u002Fcontainer\u002Fbuild.sh`\n\nSkip this step if neither lockfile changed.\n\n# Step 5: Validation\nCheck which areas changed to determine what to validate:\n- `CHANGED_FILES=$(git diff --name-only \u003Cbackup-tag-from-step-1>..HEAD)`\n\n**Host build** (always):\n- `pnpm run build`\n- `pnpm test` (do not fail the flow if tests are not configured)\n\n**Container typecheck** (only if `container\u002Fagent-runner\u002Fsrc\u002F` files are in CHANGED_FILES AND bun types are available):\n- Check: `pnpm exec tsc -p container\u002Fagent-runner\u002Ftsconfig.json --noEmit`\n- If this fails because bun types are missing (`Cannot find type definition file for 'bun'`), skip with a note — type errors will surface at container runtime instead\n\n**Container image rebuild** (only if any `container\u002F` files are in CHANGED_FILES):\n- `.\u002Fcontainer\u002Fbuild.sh`\n\nIf build fails:\n- Show the error.\n- Only fix issues clearly caused by the merge (missing imports, type mismatches from merged code).\n- Do not refactor unrelated code.\n- If unclear, ask the user before making changes.\n\n# Step 6: Breaking changes check\nAfter validation succeeds, check if the update introduced any breaking changes.\n\nDetermine which CHANGELOG entries are new by diffing against the backup tag:\n- `git diff \u003Cbackup-tag-from-step-1>..HEAD -- CHANGELOG.md`\n\nParse the diff output for lines that contain `[BREAKING]` anywhere in the line. Each such line is one breaking change entry. The format is:\n```\n[BREAKING] \u003Cdescription>. Run `\u002F\u003Cskill-name>` to \u003Caction>.\n```\n\nIf no `[BREAKING]` lines are found:\n- Skip this step silently. Proceed to Step 7 (skill updates check).\n\nIf one or more `[BREAKING]` lines are found:\n- Display a warning header to the user: \"This update includes breaking changes that may require action:\"\n- For each breaking change, display the full description.\n- Collect all skill names referenced in the breaking change entries (the `\u002F\u003Cskill-name>` part).\n- Use AskUserQuestion to ask the user which migration skills they want to run now. Options:\n  - One option per referenced skill (e.g., \"Run \u002Fadd-whatsapp to re-add WhatsApp channel\")\n  - \"Skip — I'll handle these manually\"\n- Set `multiSelect: true` so the user can pick multiple skills if there are several breaking changes.\n- For each skill the user selects, invoke it using the Skill tool.\n- After all selected skills complete (or if user chose Skip), proceed to Step 7 (skill updates check).\n\n# Step 7: Check for skill and channel\u002Fprovider updates\n\n## 7a: Skill branches\nCheck if skills are distributed as branches in this repo:\n- `git branch -r --list 'upstream\u002Fskill\u002F*'`\n\nIf any `upstream\u002Fskill\u002F*` branches exist:\n- Use AskUserQuestion to ask: \"Upstream has skill branches. Would you like to check for skill updates?\"\n  - Option 1: \"Yes, check for updates\" (description: \"Runs \u002Fupdate-skills to check for and apply skill branch updates\")\n  - Option 2: \"No, skip\" (description: \"You can run \u002Fupdate-skills later any time\")\n- If user selects yes, invoke `\u002Fupdate-skills` using the Skill tool.\n\n## 7b: Channel and provider updates\nDetect installed channels by reading `src\u002Fchannels\u002Findex.ts` and collecting all `import '.\u002F\u003Cname>.js';` lines (excluding `cli`). For providers, check `src\u002Fproviders\u002Findex.ts` the same way.\n\nIf any channels\u002Fproviders are installed AND `upstream\u002Fchannels` or `upstream\u002Fproviders` branches exist:\n- List the installed channels\u002Fproviders.\n- Use AskUserQuestion to ask: \"Would you like to update your installed channels\u002Fproviders? Re-running `\u002Fadd-\u003Cname>` is safe — it only updates code files, credentials and wiring are untouched.\"\n  - One option per installed channel\u002Fprovider (e.g., \"Update Slack (\u002Fadd-slack)\")\n  - \"Skip — I'll update them later\"\n  - Set `multiSelect: true`\n- For each selected option, invoke the corresponding `\u002Fadd-\u003Cchannel>` or `\u002Fadd-\u003Cprovider>` skill.\n\nIf no channels\u002Fproviders are installed, skip silently.\n\nProceed to Step 8.\n\n# Step 8: Summary + rollback instructions\nShow:\n- Backup tag: the tag name created in Step 1\n- New HEAD: `git rev-parse --short HEAD`\n- Upstream HEAD: `git rev-parse --short upstream\u002F$UPSTREAM_BRANCH`\n- Conflicts resolved (list files, if any)\n- Breaking changes applied (list skills run, if any)\n- Remaining local diff vs upstream: `git diff --name-only upstream\u002F$UPSTREAM_BRANCH..HEAD`\n\nTell the user:\n- To rollback: `git reset --hard \u003Cbackup-tag-from-step-1>`\n- Backup branch also exists: `backup\u002Fpre-update-\u003CHASH>-\u003CTIMESTAMP>`\n- Restart the service to apply changes. The unit\u002Flabel names are per-install — derive them with `setup\u002Flib\u002Finstall-slug.sh`. Run from your NanoClaw project root:\n  - **macOS (Darwin)**: `source setup\u002Flib\u002Finstall-slug.sh && launchctl kickstart -k gui\u002F$(id -u)\u002F$(launchd_label)`\n  - **Linux**: `source setup\u002Flib\u002Finstall-slug.sh && systemctl --user restart $(systemd_unit)` (or, if you want to confirm the unit name first: `systemctl --user list-units --type=service | grep \"$(. setup\u002Flib\u002Finstall-slug.sh && systemd_unit)\"`)\n  - **Manual** (no service found): restart `pnpm run dev`\n\n\n## Diagnostics\n\n1. Use the Read tool to read `.claude\u002Fskills\u002Fupdate-nanoclaw\u002Fdiagnostics.md`.\n2. Follow every step in that file before finishing.\n","# About\n\nYour NanoClaw fork drifts from upstream as you customize it. This skill pulls upstream changes into your install without losing your modifications.\n\nRun `\u002Fupdate-nanoclaw` in Claude Code.\n\n## How it works\n\n**Preflight**: checks for clean working tree (`git status --porcelain`). If `upstream` remote is missing, asks you for the URL (defaults to `https:\u002F\u002Fgithub.com\u002Fnanocoai\u002Fnanoclaw.git`) and adds it. Detects the upstream branch name (`main` or `master`).\n\n**Backup**: creates a timestamped backup branch and tag (`backup\u002Fpre-update-\u003Chash>-\u003Ctimestamp>`, `pre-update-\u003Chash>-\u003Ctimestamp>`) before touching anything. Safe to run multiple times.\n\n**Preview**: runs `git log` and `git diff` against the merge base to show upstream changes since your last sync. Groups changed files into categories:\n- **Skills** (`.claude\u002Fskills\u002F`): unlikely to conflict unless you edited an upstream skill\n- **Host source** (`src\u002F`): may conflict if you modified the same files\n- **Container** (`container\u002F`): triggers container rebuild\n- **Build\u002Fconfig** (`package.json`, `pnpm-lock.yaml`, `tsconfig*.json`): lockfile changes trigger dep install\n\n**Update paths** (you pick one):\n- `merge` (default): `git merge upstream\u002F\u003Cbranch>`. Resolves all conflicts in one pass.\n- `cherry-pick`: `git cherry-pick \u003Chashes>`. Pull in only the commits you want.\n- `rebase`: `git rebase upstream\u002F\u003Cbranch>`. Linear history, but conflicts resolve per-commit.\n- `abort`: just view the changelog, change nothing.\n\n**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.\n\n**Conflict resolution**: opens only conflicted files, resolves the conflict markers, keeps your local customizations intact.\n\n**Validation**: runs `pnpm run build` and `pnpm test`. If container files changed, also runs the container typecheck and `.\u002Fcontainer\u002Fbuild.sh`.\n\n**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.\n\n## Rollback\n\nThe backup tag is printed at the end of each run:\n```\ngit reset --hard pre-update-\u003Chash>-\u003Ctimestamp>\n```\n\nBackup branch `backup\u002Fpre-update-\u003Chash>-\u003Ctimestamp>` also exists.\n\n## Token usage\n\nOnly opens files with actual conflicts. Uses `git log`, `git diff`, and `git status` for everything else. Does not scan or refactor unrelated code.\n\n---\n\n# Goal\nHelp a user with a customized NanoClaw install safely incorporate upstream changes without a fresh reinstall and without blowing tokens.\n\n# Operating principles\n- Never proceed with a dirty working tree.\n- Always create a rollback point (backup branch + tag) before touching anything.\n- Prefer git-native operations (fetch, merge, cherry-pick). Do not manually rewrite files except conflict markers.\n- Default to MERGE (one-pass conflict resolution). Offer REBASE as an explicit option.\n- Keep token usage low: rely on `git status`, `git log`, `git diff`, and open only conflicted files.\n\n# Step 0: Preflight (stop early if unsafe)\nRun:\n- `git status --porcelain`\nIf output is non-empty:\n- Tell the user to commit or stash first, then stop.\n\nConfirm remotes:\n- `git remote -v`\nIf `upstream` is missing:\n- Ask the user for the upstream repo URL (default: `https:\u002F\u002Fgithub.com\u002Fnanocoai\u002Fnanoclaw.git`).\n- Add it: `git remote add upstream \u003Cuser-provided-url>`\n- Then: `git fetch upstream --prune`\n\nDetermine the upstream branch name:\n- `git branch -r | grep upstream\u002F`\n- If `upstream\u002Fmain` exists, use `main`.\n- If only `upstream\u002Fmaster` exists, use `master`.\n- Otherwise, ask the user which branch to use.\n- Store this as UPSTREAM_BRANCH for all subsequent commands. Every command below that references `upstream\u002Fmain` should use `upstream\u002F$UPSTREAM_BRANCH` instead.\n\nFetch:\n- `git fetch upstream --prune`\n\n# Step 1: Create a safety net\nCapture current state:\n- `HASH=$(git rev-parse --short HEAD)`\n- `TIMESTAMP=$(date +%Y%m%d-%H%M%S)`\n\nCreate backup branch and tag (using timestamp to avoid collisions on retry):\n- `git branch backup\u002Fpre-update-$HASH-$TIMESTAMP`\n- `git tag pre-update-$HASH-$TIMESTAMP`\n\nSave the tag name for later reference in the summary and rollback instructions.\n\n# Step 2: Preview what upstream changed (no edits yet)\nCompute common base:\n- `BASE=$(git merge-base HEAD upstream\u002F$UPSTREAM_BRANCH)`\n\nShow upstream commits since BASE:\n- `git log --oneline $BASE..upstream\u002F$UPSTREAM_BRANCH`\n\nShow local commits since BASE (custom drift):\n- `git log --oneline $BASE..HEAD`\n\nShow file-level impact from upstream:\n- `git diff --name-only $BASE..upstream\u002F$UPSTREAM_BRANCH`\n\nBucket the upstream changed files:\n- **Skills** (`.claude\u002Fskills\u002F`): unlikely to conflict unless the user edited an upstream skill\n- **Host source** (`src\u002F`): may conflict if user modified the same files\n- **Container** (`container\u002F`): triggers container rebuild (+ typecheck if `agent-runner\u002Fsrc\u002F` changed)\n- **Build\u002Fconfig** (`package.json`, `pnpm-lock.yaml`, `tsconfig*.json`): lockfile changes trigger dep install\n- **Other**: docs, tests, setup scripts, misc\n\n**Large drift check:** If the upstream commit count and age suggest the user has a lot of catching up to do, mention that `\u002Fmigrate-nanoclaw` might be a better fit — it extracts customizations and reapplies them on clean upstream instead of merging. Offer it as an option but don't push.\n\nPresent these buckets to the user and ask them to choose one path using AskUserQuestion:\n- A) **Full update**: merge all upstream changes\n- B) **Selective update**: cherry-pick specific upstream commits\n- C) **Abort**: they only wanted the preview\n- D) **Rebase mode**: advanced, linear history (warn: resolves conflicts per-commit)\n\nIf Abort: stop here.\n\n# Step 3: Conflict preview (before committing anything)\nIf Full update or Rebase:\n- Dry-run merge to preview conflicts. Run these as a single chained command so the abort always executes:\n  ```\n  git merge --no-commit --no-ff upstream\u002F$UPSTREAM_BRANCH; git diff --name-only --diff-filter=U; git merge --abort\n  ```\n- If conflicts were listed: show them and ask user if they want to proceed.\n- If no conflicts: tell user it is clean and proceed.\n\n# Step 4A: Full update (MERGE, default)\nRun:\n- `git merge upstream\u002F$UPSTREAM_BRANCH --no-edit`\n\nIf conflicts occur:\n- Run `git status` and identify conflicted files.\n- For each conflicted file:\n  - Open the file.\n  - Resolve only conflict markers.\n  - Preserve intentional local customizations.\n  - Incorporate upstream fixes\u002Fimprovements.\n  - Do not refactor surrounding code.\n  - `git add \u003Cfile>`\n- When all resolved:\n  - If merge did not auto-commit: `git commit --no-edit`\n\n# Step 4B: Selective update (CHERRY-PICK)\nIf user chose Selective:\n- Recompute BASE if needed: `BASE=$(git merge-base HEAD upstream\u002F$UPSTREAM_BRANCH)`\n- Show commit list again: `git log --oneline $BASE..upstream\u002F$UPSTREAM_BRANCH`\n- Ask user which commit hashes they want.\n- Apply: `git cherry-pick \u003Chash1> \u003Chash2> ...`\n\nIf conflicts during cherry-pick:\n- Resolve only conflict markers, then:\n  - `git add \u003Cfile>`\n  - `git cherry-pick --continue`\nIf user wants to stop:\n  - `git cherry-pick --abort`\n\n# Step 4C: Rebase (only if user explicitly chose option D)\nRun:\n- `git rebase upstream\u002F$UPSTREAM_BRANCH`\n\nIf conflicts:\n- Resolve conflict markers only, then:\n  - `git add \u003Cfile>`\n  - `git rebase --continue`\nIf it gets messy (more than 3 rounds of conflicts):\n  - `git rebase --abort`\n  - Recommend merge instead.\n\n# Step 4.5: Install dependencies (if lockfiles changed)\nCheck if the merge changed any lockfiles or package manifests:\n- `git diff \u003Cbackup-tag-from-step-1>..HEAD --name-only | grep -E '^(pnpm-lock\\.yaml|package\\.json)$'`\n  - If matched: `pnpm install`\n- `git diff \u003Cbackup-tag-from-step-1>..HEAD --name-only | grep -E '^container\u002Fagent-runner\u002F(bun\\.lock|package\\.json)$'`\n  - If matched AND `command -v bun` succeeds: `cd container\u002Fagent-runner && bun install`\n  - If bun is not installed on the host, skip — container deps will be installed during `.\u002Fcontainer\u002Fbuild.sh`\n\nSkip this step if neither lockfile changed.\n\n# Step 5: Validation\nCheck which areas changed to determine what to validate:\n- `CHANGED_FILES=$(git diff --name-only \u003Cbackup-tag-from-step-1>..HEAD)`\n\n**Host build** (always):\n- `pnpm run build`\n- `pnpm test` (do not fail the flow if tests are not configured)\n\n**Container typecheck** (only if `container\u002Fagent-runner\u002Fsrc\u002F` files are in CHANGED_FILES AND bun types are available):\n- Check: `pnpm exec tsc -p container\u002Fagent-runner\u002Ftsconfig.json --noEmit`\n- If this fails because bun types are missing (`Cannot find type definition file for 'bun'`), skip with a note — type errors will surface at container runtime instead\n\n**Container image rebuild** (only if any `container\u002F` files are in CHANGED_FILES):\n- `.\u002Fcontainer\u002Fbuild.sh`\n\nIf build fails:\n- Show the error.\n- Only fix issues clearly caused by the merge (missing imports, type mismatches from merged code).\n- Do not refactor unrelated code.\n- If unclear, ask the user before making changes.\n\n# Step 6: Breaking changes check\nAfter validation succeeds, check if the update introduced any breaking changes.\n\nDetermine which CHANGELOG entries are new by diffing against the backup tag:\n- `git diff \u003Cbackup-tag-from-step-1>..HEAD -- CHANGELOG.md`\n\nParse the diff output for lines that contain `[BREAKING]` anywhere in the line. Each such line is one breaking change entry. The format is:\n```\n[BREAKING] \u003Cdescription>. Run `\u002F\u003Cskill-name>` to \u003Caction>.\n```\n\nIf no `[BREAKING]` lines are found:\n- Skip this step silently. Proceed to Step 7 (skill updates check).\n\nIf one or more `[BREAKING]` lines are found:\n- Display a warning header to the user: \"This update includes breaking changes that may require action:\"\n- For each breaking change, display the full description.\n- Collect all skill names referenced in the breaking change entries (the `\u002F\u003Cskill-name>` part).\n- Use AskUserQuestion to ask the user which migration skills they want to run now. Options:\n  - One option per referenced skill (e.g., \"Run \u002Fadd-whatsapp to re-add WhatsApp channel\")\n  - \"Skip — I'll handle these manually\"\n- Set `multiSelect: true` so the user can pick multiple skills if there are several breaking changes.\n- For each skill the user selects, invoke it using the Skill tool.\n- After all selected skills complete (or if user chose Skip), proceed to Step 7 (skill updates check).\n\n# Step 7: Check for skill and channel\u002Fprovider updates\n\n## 7a: Skill branches\nCheck if skills are distributed as branches in this repo:\n- `git branch -r --list 'upstream\u002Fskill\u002F*'`\n\nIf any `upstream\u002Fskill\u002F*` branches exist:\n- Use AskUserQuestion to ask: \"Upstream has skill branches. Would you like to check for skill updates?\"\n  - Option 1: \"Yes, check for updates\" (description: \"Runs \u002Fupdate-skills to check for and apply skill branch updates\")\n  - Option 2: \"No, skip\" (description: \"You can run \u002Fupdate-skills later any time\")\n- If user selects yes, invoke `\u002Fupdate-skills` using the Skill tool.\n\n## 7b: Channel and provider updates\nDetect installed channels by reading `src\u002Fchannels\u002Findex.ts` and collecting all `import '.\u002F\u003Cname>.js';` lines (excluding `cli`). For providers, check `src\u002Fproviders\u002Findex.ts` the same way.\n\nIf any channels\u002Fproviders are installed AND `upstream\u002Fchannels` or `upstream\u002Fproviders` branches exist:\n- List the installed channels\u002Fproviders.\n- Use AskUserQuestion to ask: \"Would you like to update your installed channels\u002Fproviders? Re-running `\u002Fadd-\u003Cname>` is safe — it only updates code files, credentials and wiring are untouched.\"\n  - One option per installed channel\u002Fprovider (e.g., \"Update Slack (\u002Fadd-slack)\")\n  - \"Skip — I'll update them later\"\n  - Set `multiSelect: true`\n- For each selected option, invoke the corresponding `\u002Fadd-\u003Cchannel>` or `\u002Fadd-\u003Cprovider>` skill.\n\nIf no channels\u002Fproviders are installed, skip silently.\n\nProceed to Step 8.\n\n# Step 8: Summary + rollback instructions\nShow:\n- Backup tag: the tag name created in Step 1\n- New HEAD: `git rev-parse --short HEAD`\n- Upstream HEAD: `git rev-parse --short upstream\u002F$UPSTREAM_BRANCH`\n- Conflicts resolved (list files, if any)\n- Breaking changes applied (list skills run, if any)\n- Remaining local diff vs upstream: `git diff --name-only upstream\u002F$UPSTREAM_BRANCH..HEAD`\n\nTell the user:\n- To rollback: `git reset --hard \u003Cbackup-tag-from-step-1>`\n- Backup branch also exists: `backup\u002Fpre-update-\u003CHASH>-\u003CTIMESTAMP>`\n- Restart the service to apply changes. The unit\u002Flabel names are per-install — derive them with `setup\u002Flib\u002Finstall-slug.sh`. Run from your NanoClaw project root:\n  - **macOS (Darwin)**: `source setup\u002Flib\u002Finstall-slug.sh && launchctl kickstart -k gui\u002F$(id -u)\u002F$(launchd_label)`\n  - **Linux**: `source setup\u002Flib\u002Finstall-slug.sh && systemctl --user restart $(systemd_unit)` (or, if you want to confirm the unit name first: `systemctl --user list-units --type=service | grep \"$(. setup\u002Flib\u002Finstall-slug.sh && systemd_unit)\"`)\n  - **Manual** (no service found): restart `pnpm run dev`\n\n\n## Diagnostics\n\n1. Use the Read tool to read `.claude\u002Fskills\u002Fupdate-nanoclaw\u002Fdiagnostics.md`.\n2. Follow every step in that file before finishing.\n",{"name":5,"description":7},"main","85a2d934766d21e4696ac1b00157179f28bca9e3",".claude\u002Fskills\u002Fupdate-nanoclaw",2,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-10-30 04:24:16",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add microsoft\u002Famplifier-app-nanoclaw --skill update-nanoclaw",{"tool":40,"command":41},"bunx","bunx skills add microsoft\u002Famplifier-app-nanoclaw --skill update-nanoclaw",{"tool":43,"command":44},"pnpm","pnpm dlx skills add microsoft\u002Famplifier-app-nanoclaw --skill update-nanoclaw","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fupdate-nanoclaw\u002FSKILL.md",true,[48],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"diagnostics.md","REFERENCE","参考文档",1322,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fupdate-nanoclaw\u002Fdiagnostics.md",[55,64,71,82,96,109],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":20},"01M69A6E27JZN10H82TZ2GMC3A","whatsapp-formatting","Format messages for WhatsApp, including mentions that render as real WhatsApp tags. Use when responding in a WhatsApp conversation (platform_id \u002F chatJid ends with @s.whatsapp.net or @g.us).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fwhatsapp-formatting\u002FSKILL.md",[],[62,63],"whatsapp","whatsapp formatting",{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":20},"01M69A6CGJ968RNVGYTRSWZKWB","welcome","Introduce yourself to a newly connected channel. Triggered automatically when a channel is first wired. Send a friendly greeting and brief overview of what you can do.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fwelcome\u002FSKILL.md",[],[66],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":20},"01M69A6ADX690STSN63WKRD37K","vercel-cli","Deploy apps to Vercel. Use when asked to deploy, ship, or publish a web application, or manage Vercel projects, domains, and environment variables.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fvercel-cli\u002FSKILL.md",[],[78,79,80,81],"cli","vercel cli","web","deploy",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":93,"publishedAt":20},"01M69A68WJ94V4MXGXGK9T0QG7","slack-formatting","Format messages for Slack using mrkdwn syntax. Use when responding to Slack channels (folder starts with \"slack_\" or JID contains slack identifiers).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fslack-formatting\u002FSKILL.md",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[94,95],"slack","slack formatting",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":105,"publishedAt":20},"01M69A673Z17TDXK3DBC5YJFM7","self-customize","Customize your own agent — add capabilities, install packages, add MCP servers, edit code or CLAUDE.md. Use when the user asks you to add a feature, install a tool, or modify how you work. For non-trivial code changes, delegate to a builder agent via create_agent.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fself-customize\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000023","Skill与智能体开发",[106,107,108],"customize","self customize","MCP",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"publishedAt":20},"01M69A657JFNEG45Z1Y05BVK5R","onecli-gateway","OneCLI Gateway: transparent HTTPS proxy that injects stored credentials into outbound calls. You MUST use this skill when the user asks you to read emails, check calendar, access GitHub repos, create issues, check Stripe payments, or interact with ANY external service or API. Do NOT use browser extensions or OAuth CLI tools. Make HTTP requests directly; the gateway injects credentials automatically.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-nanoclaw\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fonecli-gateway\u002FSKILL.md",[115],{"categoryNo":103,"categoryName":104,"taxonomyType":91,"taxonomyTypeDesc":92},[117,78,118,119],"onecli gateway","github","repos"]