update · diff

git:20261006.cc10712 to git:20261006.0297cbd

40 added, 19 removed. Audit A to A.

---

name: update

description: |

Safe cc10x upgrade through the Claude Code plugin CLI.

Lists every installed scope, refreshes the marketplace, updates each scope,

and optionally carries local patches over to the new install.

Use this skill when: updating cc10x, upgrading, pulling latest cc10x,

syncing plugin, refreshing cache, or checking for new versions.

Triggers: update cc10x, upgrade cc10x, pull cc10x, sync plugin, refresh cc10x,

check for updates, new version, update plugin, upgrade plugin.

allowed-tools: Read, Bash, AskUserQuestion

---

# cc10x Update

Upgrade cc10x with the `claude plugin` CLI. The CLI owns the plugin registry and the install cache; this skill never edits either one directly and never assumes where they live.

- **Workflow:** Discover installs → Refresh marketplace → (optional) Capture local patches → Update each scope → Re-apply patches → Restart or reload.

+ **Workflow:** Discover installs → Locate the marketplace → (optional) Capture local patches → Refresh marketplace → Update each scope → Re-apply patches → Restart or reload.

+ Capture comes before the refresh on purpose: `marketplace update` moves the marketplace checkout to the new version, so afterwards the old version can no longer be read from it as a baseline.

## Phase 1: Discovery

```bash

claude plugin list --json

```

The output is a JSON array. Keep only entries whose `id` is `cc10x@cc10x`. Each entry has `version`, `scope` (`user`, `project`, `local`, or `managed`), `enabled`, `installPath`, and, for `project` and `local` scopes, `projectPath`.

- The same plugin can appear several times: once per scope, and once per project for `project` and `local` scopes. Different entries may point at different versions and different `installPath` values. Show the user one row per entry (scope, `projectPath` if present, version, `installPath`).

+ The same plugin can appear several times: once per scope, and once per project for `project` and `local` scopes. Different entries may point at different versions and different `installPath` values.

If no `cc10x@cc10x` entry exists → STOP and tell the user cc10x is not installed (install it with `claude plugin install cc10x@cc10x`).

- ## Phase 2: Refresh The Marketplace

+ Show the user one row per entry (scope, `projectPath` if present, version, `installPath`). For a `project` or `local` entry whose `projectPath` no longer exists on disk, mark it "skipped: project directory no longer exists"; it cannot be updated from there.

+ ## Phase 2: Locate The Marketplace

```bash

- claude plugin marketplace update cc10x

+ claude plugin marketplace list --json

```

- Installed versions only change in Phase 4. To learn the available version, read `.claude-plugin/plugin.json` under the marketplace plugin directory (locate it as in Phase 3, step 1). If every entry already matches that version → report "already up to date" and STOP.

- **Gate:** show installed versus available versions and ask the user which scopes to update.

+ Take the entry named `cc10x` and set `LOC` to its `installLocation`. The plugin source is `$LOC/plugins/cc10x`. If the entry or that directory is missing → STOP and tell the user the marketplace is not registered (`claude plugin marketplace add romiluz13/cc10x`).

## Phase 3: Capture Local Patches (Optional)

- Skip this phase if the user has not modified cached files.

+ Skip this phase if the user has not modified cached files. Run it before Phase 4.

- 1. Locate the marketplace source: `claude plugin marketplace list --json`, take the entry named `cc10x`, and use its `installLocation`. The plugin source is `<installLocation>/plugins/cc10x`. If that directory is missing, skip patch carry-over and say so.

- 2. For each entry being updated, list the differing files between the marketplace source and its old `installPath`: `diff -rq "<installLocation>/plugins/cc10x" "<old installPath>"`. Entries that share an `installPath` share one result; capture it once. Ignore differences that exist only because the old version is older than the marketplace version; local patches are the files the user edited, so compare against the marketplace source at the old version when the versions differ (`git -C "<installLocation>" log` can locate it) or ask the user which files they changed.

- 3. For each locally modified file, save a per-file patch (pristine to locally modified, so applying it later re-adds the user's changes):

+ For each distinct old `version` among the entries to update, pin the pristine baseline: the commit that set that version in the marketplace checkout.

- ```bash

- diff -u "<pristine file>" "<old installPath>/<file>" > "<backup dir>/<file with / replaced by __>.patch"

- ```

+ ```bash

+ SHA=$(git -C "$LOC" log --format=%H -S"\"version\": \"<old>\"" -- plugins/cc10x/.claude-plugin/plugin.json | tail -1)

+ git -C "$LOC" show "$SHA:plugins/cc10x/.claude-plugin/plugin.json"

+ ```

- Use a backup directory the user approves (for example a `cc10x-update-backup-<date>` directory under the system temp directory). Report which files were modified, and list files present only in the old `installPath`.

+ `tail -1` takes the oldest match, the commit that introduced the version string. The `show` output must contain `"version": "<old>"`. If `SHA` is empty or the `show` output does not match (a shallow checkout or pruned history is the usual cause) → ABORT carry-over: tell the user local modifications cannot be separated from upstream content for that version, and ask whether to continue the update without carry-over or stop so they can back up their changes by hand. Do not guess a baseline from the new marketplace version.

+ With a pinned `SHA`, for each file in `git -C "$LOC" ls-tree -r --name-only "$SHA" -- plugins/cc10x`, save a per-file patch (pristine to locally modified, so applying it later re-adds the user's changes). A file that differs exits 1 from `diff`; a file missing from the install, or any exit 2, is reported rather than patched:

+ ```bash

+ git -C "$LOC" show "$SHA:plugins/cc10x/<file>" | diff -u - "<old installPath>/<file>" > "<backup dir>/<file with / replaced by __>.patch"

+ ```

+ Entries that share an `installPath` share one result; capture it once. Use a backup directory the user approves (for example a `cc10x-update-backup-<date>` directory under the system temp directory). Report the modified files, files missing from the install, and files present only in the old `installPath`.

**Gate:** if local modifications exist, ask: "Save these patches and carry them over after the update?"

- ## Phase 4: Update Each Scope

+ ## Phase 4: Refresh The Marketplace

+ ```bash

+ claude plugin marketplace update cc10x

+ ```

+ If it exits non-zero, show its output and STOP: the available version is unknown, so do not claim success or continue to Phase 5. Saved patches stay in the backup directory.

+ Installed versions only change in Phase 5. To learn the available version, read `.claude-plugin/plugin.json` under `$LOC/plugins/cc10x`. If every entry already matches that version → report "already up to date" and STOP.

+ **Gate:** show installed versus available versions and ask the user which scopes to update.

+ ## Phase 5: Update Each Scope

For each selected entry:

```bash

claude plugin update cc10x@cc10x --scope <scope>

```

- For `project` and `local` entries, run the command from the entry's `projectPath` so the CLI resolves the right project. Do not run it for `managed` scope; tell the user managed installs are updated by whoever administers them.

+ For `project` and `local` entries, run the command from the entry's `projectPath` so the CLI resolves the right project; if that directory no longer exists, skip the entry and say so. Do not run it for `managed` scope; tell the user managed installs are updated by whoever administers them.

If a command fails, report its output and continue with the remaining scopes; do not retry with other flags.

- ## Phase 5: Re-apply Patches

+ ## Phase 6: Re-apply Patches

Run `claude plugin list --json` again and read the new `installPath` for each updated entry. For each saved patch, apply it to the same file under the new `installPath` (the explicit target file makes header paths irrelevant):

```bash

patch --forward "<new installPath>/<file>" "<patch file>"

```

If a hunk is rejected (a `.rej` file), show both versions and ask the user how to resolve it. Copy files that existed only in the old `installPath` into the new one. Report patches applied clean, conflicts, and files restored.

- ## Phase 6: Restart Or Reload

+ ## Phase 7: Restart Or Reload

Updates apply only to a fresh session. Tell the user to restart Claude Code or run `/reload-plugins`. Report old version → new version for each scope updated.

You cannot restart or reload the session yourself, and you cannot verify the new version is active until the user does.