@reyanshgupta/ditto-cli 0.3.4 → 0.3.5

package/README.md

@@ -131,7 +131,7 @@ ditto-cli update --check   # compare versions without installing
 ditto-cli update --git     # install from the Git repository instead
 ```
 
-`update` runs `cargo install` for you, so it needs Rust on your `PATH`. It stops early when you already have the newest release. Asking crates.io for the published version needs a network connection; without one it says so and installs anyway.
+`update` runs `cargo install` for you, so it needs Rust on your `PATH`. It stops early when you already have the newest release. During a build it shows a compact animated status instead of Cargo's full compilation log; if the build fails, it prints that log so the error is not hidden. Asking crates.io for the published version needs a network connection; without one it says so and installs anyway.
 
 `update` only replaces a copy in Cargo's own bin directory. Run it against a Homebrew install, or a binary from the [releases page](https://github.com/reyanshgupta/ditto-cli/releases), and it says so before it starts, then leaves that copy alone: a `cargo install` would land in a different directory and shadow the existing binary rather than replace it. Use `brew upgrade ditto-cli` or the newer archive instead.
 
@@ -502,6 +502,20 @@ ditto-cli sync client-a           # link what can be linked, report what cannot
 ditto-cli sync client-a --adopt   # replace the profile's own copies too
 ```
 
+### Downloaded skills
+
+Sharing a directory by linking it has one cost, and Ditto CLI pays it for you.
+
+A skill installer — `npx skills add`, and anything else that installs into more than one agent — puts the skill somewhere central and then records it in each agent's skills directory as a *relative* link, computed from the directory the agent was pointed at. Under a profile that directory is one of the links above, so the operating system writes the record into your own configuration instead, where the same relative path leads somewhere else. The skill lands on disk intact and is readable from nowhere, in every profile at once.
+
+Ditto CLI is what moved the directory, so Ditto CLI is what can say where those links meant to point. Launching a tool repairs its own, which is the moment before it reads them, and says so:
+
+```
+ditto-cli: repaired claude/skills/apple-design; it was installed pointing at nothing
+```
+
+`ditto-cli sync <profile>` does the same for every tool at once and reports them under `repaired`. A link is only rewritten when reading it against the path the installer was given names something that exists, so a link that is relative and broken for reasons of its own is left exactly as it is.
+
 ## Where credentials and files are stored
 
 Ditto CLI does not ask for passwords, parse OAuth tokens, or keep credentials in its state file. Claude Code, Codex, and opencode authentication still runs through their installed CLIs, and OMP and Prime Agent authentication through `/login` inside their interfaces. Each tool stores the result wherever it normally would, under the directory Ditto CLI pointed it at:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@reyanshgupta/ditto-cli",
-  "version": "0.3.4",
+  "version": "0.3.5",
   "description": "Switch between Claude Code, Codex, opencode, OMP, and Prime Agent accounts",
   "keywords": [
     "claude-code",
@@ -33,9 +33,9 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@reyanshgupta/ditto-cli-darwin-arm64": "0.3.4",
-    "@reyanshgupta/ditto-cli-darwin-x64": "0.3.4",
-    "@reyanshgupta/ditto-cli-linux-x64": "0.3.4",
-    "@reyanshgupta/ditto-cli-win32-x64": "0.3.4"
+    "@reyanshgupta/ditto-cli-darwin-arm64": "0.3.5",
+    "@reyanshgupta/ditto-cli-darwin-x64": "0.3.5",
+    "@reyanshgupta/ditto-cli-linux-x64": "0.3.5",
+    "@reyanshgupta/ditto-cli-win32-x64": "0.3.5"
   }
 }