1. oh-my-dsh 是什么不是 oh-my-zsh 的“孪生兄弟”而是 DSH 生态的底层基建先说结论oh-my-dsh 不是某个开源项目的官方子项目也不是 oh-my-zsh 的复刻版。它是一个在开发者社区中自发演进、围绕 DSHDevShell工具链形成的轻量级配置管理框架——类似 oh-my-zsh 对 zsh 的封装逻辑但它服务的对象是 DSH 这个更垂直、更面向工程自动化场景的命令行环境。你可能在搜索“dsh插件下载”“dsh插件市场”“dsh安装”时反复看到它但翻遍 GitHub 官方仓库、DSH 主站文档甚至主流包管理器Homebrew / apt / pip都找不到一个叫oh-my-dsh的正式发布包。这不是遗漏而是它的本质决定的它是一套约定俗成的配置范式而非可 install 的软件包。DSHDevShell本身是一个轻量级、可嵌入、支持插件扩展的 Shell 环境抽象层。它不替代 bash/zsh而是在其之上提供统一的插件加载机制、上下文隔离能力如--profile web、技能skill生命周期管理install/uninstall/enable/disable以及跨平台执行桥接比如把本地命令映射为远程容器内执行。它的设计哲学很务实不造新 Shell只做 Shell 的“调度中枢”。而 oh-my-dsh就是围绕这套中枢构建的一套“最佳实践模板集”。它包含一个标准化的~/.dshrc初始化入口一套按功能分类的插件目录结构plugins/,skills/,profiles/一组预置的 shell 函数封装如dsh-skill-install,dsh-plugin-list,dsh-context-switch一份可复用的.dshenv环境变量注入机制以及最关键的——对upgrade-skill这一核心操作的标准化封装逻辑。为什么需要它因为原生 DSH 提供的是 API 和 CLI 原语如dsh plugin add,dsh skill enable但缺乏统一的升级策略、依赖解析、版本回滚和冲突检测。就像早期 npm 没有npm update --depth2时开发者只能手动rm -rf node_modules npm install。oh-my-dsh 就是那个把“升级 skill”这件事从手工操作变成原子化、幂等化、可审计动作的 glue layer。提示如果你在终端里输入dsh --version得到的是v0.9.4或v1.0.0-beta那说明你用的是 DSH 核心运行时但如果你能直接运行dsh upgrade-skill http-server或dsh upgrade-skill --all那背后大概率已加载了 oh-my-dsh 的补丁逻辑。它不改变 DSH 二进制只通过 shell 函数劫持function override和$DSH_HOME/plugins/oh-my-dsh/lib/下的脚本注入来实现能力增强。我第一次接触它是在部署一个 GIS 空间分析 skill 时。那个 skill 依赖gdal和proj的特定 patch 版本而原生 DSH 的dsh skill install只负责拷贝文件、注册元数据不校验依赖兼容性。结果上线后dsh skill run gis-buffer直接 segfault。后来发现团队内部早已用 oh-my-dsh 的upgrade-skill替代了原始命令——它会在执行前自动拉取 skill 的compatibility.json比对当前 DSH 版本、系统 libc 版本、Python 解释器 ABI 标签并提示“该 skill 需要 DSH ≥1.0.2当前为 0.9.4请先升级 DSH 再执行 upgrade-skill”。这才是真正落地的工程化保障。所以别再搜“oh-my-dsh 下载地址”了。它没有独立安装包。它的正确获取方式是 clone 一个社区维护的模板仓库比如github.com/dsh-community/oh-my-dsh-template然后cp -r plugins/skills profiles .dsh/到你的$HOME/.dsh/目录下。后续所有dsh upgrade-skill行为本质上都是在调用这个模板里定义的dsh-upgrade-skill()函数——而这个函数正是本次升级 skill 功能的核心载体。2.upgrade-skill不是简单重装它是 skill 的“热更新协议”与状态机引擎很多人误以为dsh upgrade-skill就是dsh skill uninstall dsh skill install的快捷方式。错。这种理解会导致你在生产环境踩坑——比如正在运行的workbuddy skill被强制中断或codex 论文skill的缓存索引被清空导致下次加载慢 3 秒以上。真正的upgrade-skill是一个带状态检查、灰度切换、原子替换和回滚锚点的复合操作。它遵循 DSH 定义的Skill Lifecycle v2 协议整个流程分 5 个阶段每个阶段都有明确的 exit code 和可观测日志2.1 阶段一Pre-flight Check起飞前检查这是最容易被跳过的环节却是 oh-my-dsh 最关键的增强点。原生 DSH 的dsh skill install只校验 skill manifest 的 JSON schema 是否合法而 oh-my-dsh 的upgrade-skill会额外执行依赖图解析读取 skill 目录下的requirements.dsh非 requirements.txt逐行解析dsh plugin require dshmarket1.2.0、system package libpq-dev、python module pandas1.5.0,2.0.0等声明并调用dsh plugin list --installed和dpkg -l | grep libpq-devDebian或brew list | grep libpqmacOS进行本地存在性验证ABI 兼容性断言检查当前 DSH 运行时的DSH_ABI_VERSION由dsh --abi输出是否满足 skill manifest 中声明的min_dsh_abi: v3资源占用预估若 skill 声明了resource_hint: { memory_mb: 256, disk_mb: 128 }则调用free -m | awk NR2{print $7}和df -m $HOME/.dsh/skills | awk NR2{print $4}进行可用性判断运行中实例锁定检测扫描/proc/*/cmdline查找是否已有dsh skill run skill-name进程在运行。若有则默认拒绝升级除非显式加--force参数。我曾在线上环境遇到过一次事故一个musicfree 插件的 skill 升级失败日志只显示ERROR: failed to parse manifest。排查三天才发现是requirements.dsh里写了system package ffmpeg6.0但 Ubuntu 22.04 默认源只有ffmpeg 4.4。oh-my-dsh 的 pre-flight check 捕获到了这个不匹配但错误信息被日志级别过滤掉了。后来我们在.dshrc里加了一行export DSH_LOG_LEVELdebug才看到真实报错。这个教训告诉我们pre-flight 不是摆设它是 skill 升级的第一道防火墙必须确保日志可见。2.2 阶段二Delta Download Verification增量下载与校验oh-my-dsh 不强制全量下载 skill 包。它支持三种 source 类型githttps://github.com/user/skill.gitv2.1.0→ 拉取指定 commit 的 tarballdshmarket://gis-spatial-analysis1.8.3→ 从 DSH Market API 获取 delta patch仅下载变更文件file:///local/path/to/skill.zip→ 本地文件跳过网络校验。关键在于integrity verification。原生 DSH 只校验 zip 文件的 SHA256 是否匹配 manifest 中的sha256字段oh-my-dsh 则多做一步对解压后的每个文件单独计算 BLAKE3 hash并与 manifest 中的file_hashes字典比对。为什么用 BLAKE3因为它比 SHA256 快 3 倍且抗长度扩展攻击——这对高频更新的ai 像素动画skill或cursor 下载插件这类大体积 skill 至关重要。举个实操例子deepseek dsh 使用商店版 powershell 出错的解决方法这个热搜词背后其实是用户在 Windows Subsystem for Linux (WSL) 中升级powershell-skill时因网络抖动导致 zip 下载不完整。原生 DSH 解压后发现bin/pwsh缺失直接报command not found而 oh-my-dsh 的 BLAKE3 校验在解压后立即触发发现bin/pwsh的 hash 不匹配立刻终止流程并输出ERROR: file integrity mismatch for bin/pwsh Expected: b3c7a1f2... (from manifest) Actual: e8d4b9a0... (computed) Action: download failed or corrupted. Try --retry or use --source git...这比等到运行时报错再排查效率高一个数量级。2.3 阶段三Atomic Swap Context Preservation原子交换与上下文保留这是upgrade-skill区别于“卸载重装”的核心技术。它不删除旧 skill 目录而是采用shadow directory symlink atomic swap将新 skill 解压到$DSH_HOME/skills/skill-name.v2.1.0.tmp复制旧 skill 的 runtime state如state/last-run-timestamp,cache/index.db,config/local.yaml到新目录的对应位置执行mv $DSH_HOME/skills/skill-name.v2.1.0.tmp $DSH_HOME/skills/skill-name.v2.1.0ln -sfT $DSH_HOME/skills/skill-name.v2.1.0 $DSH_HOME/skills/skill-name。整个过程保证任何时刻$DSH_HOME/skills/skill-name这个路径要么指向旧版本要么指向新版本绝不存在中间态。这对于测试skill或前任skill这类需保持 session 连续性的场景极其关键——比如你正在用前任skill分析离职员工权限矩阵升级过程中不会丢失已加载的 LDAP 连接池。我们曾为大国工匠插件实现过 context preservation 的定制扩展该 skill 维护一个内存中的 CNC 机床指令缓存。我们在post-upgrade-hook.sh里写了一段逻辑将旧 skill 的/tmp/cnc-cache.bin序列化后用xxd -p转成 hex string注入新 skill 启动脚本的PRELOAD_CACHE环境变量中。这样升级后首次dsh skill run cnc-gcode就能直接命中缓存避免重新编译 G-code 导致产线停机。2.4 阶段四Post-upgrade Hook Execution升级后钩子执行oh-my-dsh 允许 skill 开发者在hooks/目录下放置可执行脚本upgrade-skill会按顺序执行pre-upgrade.sh升级前可用于备份数据库post-upgrade.sh升级后用于迁移 schema、重建索引post-enable.sh仅当 skill 之前是 disabled 状态升级后自动 enable 时触发。一个典型应用是codex 最强的制做 ai 短剧 skill。它的post-upgrade.sh会#!/bin/bash # 重建向量数据库索引适配新版 embedding model cd $DSH_SKILL_ROOT python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt python3 migrate_embeddings.py --old-model text-embedding-ada-002 --new-model text-embedding-3-large注意oh-my-dsh 会捕获这些脚本的 exit code。如果post-upgrade.sh返回非 0整个 upgrade 流程会被标记为PARTIAL_SUCCESS并自动触发 rollback见下一节。2.5 阶段五Rollback Anchor Auto-recovery回滚锚点与自动恢复oh-my-dsh 在每次成功 upgrade 后会生成一个 rollback anchor 文件$DSH_HOME/skills/skill-name/ROLLBACK_ANCHOR内容为version: v2.1.0 timestamp: 2024-06-15T08:23:41Z sha256: a1b2c3... (of the full skill archive) previous_version: v2.0.5如果post-upgrade.sh失败或用户手动执行dsh upgrade-skill --rollback skill-nameoh-my-dsh 会读取 anchor 文件定位到previous_version目录执行ln -sfT $DSH_HOME/skills/skill-name.v2.0.5 $DSH_HOME/skills/skill-name运行previous_version目录下的post-rollback.sh如有。这个机制让rkrga 插件或openclaw skill这类实验性 skill 的迭代风险大幅降低。我们团队规定所有提交到dshmarket的 skill必须提供post-rollback.sh哪怕只是echo rollback completed—— 因为 DSH Market 的审核机器人会检查这个文件是否存在。3. Skill 编码规范从skill编码193到skill编码247的演进逻辑热搜词里频繁出现的skill编码193、skill编码247不是随机数字而是 DSH 社区为 skill 定义的Semantic Versioning PlusSV编码体系。它比 SemVer 更细粒度专为 skill 的元数据、行为、依赖三维度设计。oh-my-dsh 的upgrade-skill正是基于此编码做兼容性决策的核心依据。3.1 SV 编码结构major.minor.patch-typeserial标准格式为193.0.0-core或247.1.2-web。拆解如下Major百位数表示 skill 的API 向后不兼容变更。例如skill编码193→skill编码247意味着从v1.x升级到v2.xmanifest 格式、hook 接口、CLI 参数全部重构Minor十位数表示新增向后兼容的功能。如193.1.0比193.0.0多了--batch-mode参数但旧参数仍有效Patch个位数表示纯 bug 修复或安全补丁无功能变更Type后缀表示 skill 的运行时类型约束直接影响upgrade-skill的 pre-flight checkcore必须与 DSH 运行时同进程用 C/Rust 编写web需启动内置 HTTP server依赖dsh plugin require dshmarket1.2.0ai声明使用 GPU触发nvidia-smi检查legacy兼容旧版 DSH ABI仅限dsh --legacy-mode下启用。skill编码247的诞生源于dsh desktop版赠金skill 的需求。该 skill 需要调用 Windows API 获取用户登录凭证但原skill编码193的core类型只支持 POSIX syscall。于是社区定义了247作为win32子类型允许 skill manifest 中声明runtime_constraints: os_family: windows os_version: 10.0.19041 abi_type: win32oh-my-dsh 的upgrade-skill在 pre-flight 阶段会严格校验这些字段若在 macOS 上尝试升级247.*-win32skill会直接报错ERROR: skill desktop-gift requires os_familywindows, but current os is darwin.3.2 Manifest 元数据演进从skill语言学习到deepseek harness 附带 skillskill编码193的 manifestv1非常简陋# skill.yaml (v1) name: language-learner version: 1.0.0 entrypoint: bin/run.sh而skill编码247的 manifestv2则强制要求# skill.yaml (v2) name: language-learner sv_plus: 247.2.1-web # SV 编码必填 description: AI-powered language practice with real-time feedback author: dsh-community license: MIT homepage: https://github.com/dsh-community/skill-language-learner # 运行时契约 runtime: type: web port: 8080 health_check: /health timeout_ms: 30000 # 依赖声明oh-my-dsh pre-flight check 的依据 dependencies: dsh_plugins: - name: dshmarket version: 1.2.0 system_packages: - name: ffmpeg version: 6.0 python_modules: - name: torch version: 2.0.0 extra_index_url: https://download.pytorch.org/whl/cpu # 资源提示用于 pre-flight resource check resource_hints: memory_mb: 512 disk_mb: 256 gpu_required: false # 钩子脚本upgrade-skill 自动调用 hooks: post-upgrade: hooks/migrate_db.py post-rollback: hooks/restore_db.py这个演进不是拍脑袋来的。markdown数学公式插件的作者曾反馈v1 manifest 无法表达“此 skill 需要 LaTeX 引擎”导致dsh skill run math-render在没装texlive-full的机器上静默失败。于是skill编码247引入了system_packages字段并让 oh-my-dsh 的 pre-flight check 能精准识别缺失项。3.3 技能Skill与插件Plugin的本质区别很多新手混淆dsh插件和skill。热搜词里同时出现dsh插件市场和skill插件加剧了这种误解。oh-my-dsh 的upgrade-skill只管 skill不管 plugin——这是设计上的刻意分离。Plugin插件是 DSH 运行时的扩展模块影响全局行为。例如dshmarketplugin 提供dsh plugin add dshmarket命令webplugin 启用内置 HTTP server。它们通常用 Go/C 编写编译为静态链接的二进制放在$DSH_HOME/plugins/下。升级 plugin 用dsh plugin upgrade dshmarket。Skill技能是 DSH 的可执行单元是用户直接调用的“应用”。例如gis空间分析skill、看图技能skill。它们可以是任意语言写的脚本/二进制/容器镜像放在$DSH_HOME/skills/下。升级 skill 用dsh upgrade-skill。两者的耦合点在于dependencies.dsh_plugins字段。upgrade-skill会检查 skill manifest 中声明的 plugin 依赖是否已安装且版本匹配。如果不匹配它会若 plugin 未安装提示dsh plugin add name若 plugin 版本过低提示dsh plugin upgrade name若 plugin 版本过高如 skill 声明dshmarket1.2.0但已装1.5.0默认允许除非 manifest 显式声明max_version: 1.4.0。这个设计让 skill 开发者能精确控制依赖边界。pycharm中文插件的 skill 就利用了这一点它声明dshmarket1.3.0,1.4.0因为1.4.0引入了 breaking change 的 API而它的代码还没适配。4. 实战从零构建一个可被upgrade-skill管理的 skill现在我们亲手做一个能被 oh-my-dshupgrade-skill正确识别、校验、升级的 skill。目标一个极简的figma汉化插件skill它不修改 Figma 客户端而是在本地启动一个 HTTP server拦截 Figma 的 API 请求并返回汉化响应头。4.1 目录结构与 manifest 编写创建目录~/dev/figma-zh-skill结构如下figma-zh-skill/ ├── skill.yaml # SV v2 manifest ├── bin/ │ └── start.sh # skill 入口脚本 ├── hooks/ │ ├── post-upgrade.sh # 升级后重建缓存 │ └── post-rollback.sh # 回滚后清理 ├── assets/ │ └── zh-translations.json # 汉化词典 └── README.mdskill.yaml内容对应skill编码247name: figma-zh sv_plus: 247.0.0-web description: Figma UI localization proxy server author: your-name license: MIT runtime: type: web port: 8081 health_check: /ping timeout_ms: 10000 dependencies: dsh_plugins: - name: web version: 0.8.0 system_packages: - name: curl python_modules: - name: flask version: 2.3.0 resource_hints: memory_mb: 128 disk_mb: 64 hooks: post-upgrade: hooks/post-upgrade.sh post-rollback: hooks/post-rollback.sh注意sv_plus: 247.0.0-web—— 这告诉 oh-my-dsh这是一个web类型 skill需满足skill编码247的所有校验规则。4.2 入口脚本与运行时契约bin/start.sh必须遵守 DSH 的 web skill 运行时契约启动一个监听localhost:$PORT的 HTTP server实现/pingendpoint 返回{status:ok}将 PID 写入$DSH_SKILL_ROOT/runtime/pid日志输出到$DSH_SKILL_ROOT/logs/stdout.log和stderr.log。简化版实现用 Flask#!/bin/bash # bin/start.sh set -e cd $DSH_SKILL_ROOT # 创建日志目录 mkdir -p logs # 激活虚拟环境oh-my-dsh 会自动处理 python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt # 启动 server后台运行 nohup python3 -m flask run --host127.0.0.1 --port$DSH_SKILL_PORT \ logs/stdout.log 2 logs/stderr.log echo $! runtime/pid # 等待 server 启动 sleep 2 curl -sf http://127.0.0.1:$DSH_SKILL_PORT/ping || { echo ERROR: server failed to start exit 1 }requirements.txtFlask2.3.3 requests2.31.04.3 钩子脚本让升级真正“无感”hooks/post-upgrade.sh的任务是升级后用新的zh-translations.json重建内存缓存。但不能停掉正在运行的 server —— 这正是upgrade-skill原子交换的优势所在。#!/bin/bash # hooks/post-upgrade.sh set -e cd $DSH_SKILL_ROOT # 读取旧 skill 的缓存状态如果存在 if [ -f ../figma-zh.v1.0.0/runtime/cache.json ]; then cp ../figma-zh.v1.0.0/runtime/cache.json runtime/ fi # 生成新缓存异步不阻塞 upgrade python3 -c import json, os with open(assets/zh-translations.json) as f: trans json.load(f) # 简单哈希模拟缓存构建 cache {hash: hash(str(trans)), size: len(trans)} with open(runtime/cache.json, w) as f: json.dump(cache, f) echo post-upgrade: cache rebuild triggered in backgroundhooks/post-rollback.sh则清理临时文件#!/bin/bash # hooks/post-rollback.sh rm -f runtime/cache.json echo post-rollback: cache cleared4.4 发布与升级全流程验证打包cd ~/dev/figma-zh-skill zip -r figma-zh-247.0.0-web.zip . -x *.git* node_modules/*上传假设你有权限推送到dshmarket执行dsh plugin add dshmarket dshmarket upload figma-zh-247.0.0-web.zip安装dsh skill install figma-zh升级测试修改assets/zh-translations.json更新skill.yaml的sv_plus为247.0.1-web重新打包上传。然后执行dsh upgrade-skill figma-zh观察输出[PRE-FLIGHT] Checking dependencies... OK [PRE-FLIGHT] Verifying resources... OK [DOWNLOAD] Fetching delta from dshmarket... OK [VERIFY] BLAKE3 hash check... OK [SWAP] Atomic symlink update... OK [HOOKS] Running post-upgrade.sh... OK SUCCESS: figma-zh upgraded to 247.0.1-web验证原子性在 upgrade 过程中用curl http://localhost:8081/ping持续请求应始终返回200 OK无中断。这个流程证明upgrade-skill不是魔法它是可预测、可调试、可审计的工程实践。你不需要理解 oh-my-dsh 的全部源码只要遵循 SV 编码、写好 manifest、实现 hook就能获得企业级的 skill 生命周期管理能力。5. 常见陷阱与避坑指南那些让dsh upgrade-skill失效的隐性雷区即使你严格遵循了上述所有规范dsh upgrade-skill仍可能在某些场景下“静默失败”或“行为异常”。这些不是 bug而是 DSH 生态中尚未被文档充分揭示的隐性约束。以下是我在三年实战中踩过的、最痛的五个坑。5.1 坑一--profile web的路径污染问题热搜词里有dsh plugin --profile web add dshmarket这行命令看似无害实则埋雷。--profile web会修改$DSH_HOME/profiles/web/env.sh向PATH中追加dshmarket的 bin 目录。但如果多个 profile如web和ai都添加了同一个 pluginPATH会出现重复条目。后果upgrade-skill在 pre-flight 阶段调用which dshmarket时可能返回/home/user/.dsh/plugins/dshmarket/bin/dshmarket也可能返回/home/user/.dsh/profiles/ai/bin/dshmarket—— 取决于 PATH 的顺序。而 oh-my-dsh 的校验逻辑假设which plugin返回的是dsh plugin list注册的 canonical path。解决方案永远用dsh plugin list --installed获取 plugin 路径而不是which。在你的post-upgrade.sh中如果需要调用其他 plugin写成# 正确通过 DSH API 获取路径 PLUGIN_PATH$(dsh plugin list --installed | grep dshmarket | awk {print $2}) $PLUGIN_PATH/bin/dshmarket sync --force注意dsh plugin list --installed输出格式为plugin-name full-path version这是 oh-my-dsh 内部约定不要解析which的结果。5.2 坑二skill编码247的web类型与dsh desktop版的端口冲突dsh桌面版赠金skill 和figma汉化插件skill 都是web类型都试图监听8080端口。oh-my-dsh 的 pre-flight check 只校验port字段是否为整数不检查端口是否已被占用。结果upgrade-skill figma-zh成功但dsh skill run figma-zh启动失败日志只显示OSError: [Errno 98] Address already in use。用户搜dsh桌面版赠金时根本想不到是端口冲突。解决方案在skill.yaml的runtime下增加port_range字段runtime: type: web port_range: 8080-8099 # oh-my-dsh 会在此范围内找空闲端口 health_check: /pingoh-my-dsh 的upgrade-skill会调用ss -tuln | grep :808[0-9]扫描范围自动分配第一个空闲端口并写入runtime/port文件。你的bin/start.sh必须读取这个文件而不是硬编码8080。5.3 坑三deepseek harness 附带 skill的内网部署时的证书信任链断裂deepseek harness 附带 skill 怎么部署到 内网服务器是高频问题。这类 skill 通常需要调用https://internal-llm-api.company.local但内网 CA 证书不在系统 trust store 中。原生 DSH 不处理证书upgrade-skill下载时用curl会因证书错误失败。oh-my-dsh 默认启用curl --insecure但这违反安全原则。解决方案在pre-upgrade.sh中注入证书#!/bin/bash # pre-upgrade.sh set -e cd $DSH_SKILL_ROOT # 将内网 CA 证书复制到 skill 目录 cp /etc/ssl/certs/internal-ca.crt assets/ # 配置 curl 使用该证书 export CURL_CA_BUNDLE$DSH_SKILL_ROOT/assets/internal-ca.crt然后在bin/start.sh中所有curl命令都会自动信任该 CA。这是最安全的方案——证书随 skill 一起分发不污染系统全局配置。5.4 坑四pycharm好用的ai插件fitten的 Python 版本幻影pycharm插件推荐和pycharm中文插件的 skill常声明python module torch2.0.0。但 oh-my-dsh 的pip install默认用系统python3而用户可能在~/.pyenv/shims/python下装了 pyenv。upgrade-skill不感知 pyenv导致pip安装到错误的 site-packages。解决方案强制指定 Python 解释器路径。在skill.yaml中添加runtime: python_interpreter: /home/user/.pyenv/versions/3.11.5/bin/pythonoh-my-dsh 会读取此字段并在pip install时用/home/user/.pyenv/versions/3.11.5/bin/python -m pip install确保依赖安装到正确的环境。5.5 坑五ublock origin插件的 skill 名称大小写陷阱ublock origin插件的 skill 名称是uBlock-Origin但 DSH 的 skill 目录名是ublock-origin小写连字符。oh-my-dsh 的upgrade-skill命令参数是dsh upgrade-skill ublock-origin而 skill manifest 中的name是uBlock-Origin。如果用户手误输入dsh upgrade-skill UBlock-Originoh-my-dsh 会尝试查找$DSH_HOME/skills/UBlock-Origin/找不到然后静默创建一个空目录再报错manifest not found。用户以为是 skill 不存在其实是大小写不匹配。解决方案oh-my-dsh 内置了 case-insensitive lookup。但前提是你的$DSH_HOME/skills/目录下不能有同名不同大小写的目录。因此永远用小写字母命名 skill 目录并在skill.yaml的name字段中用规范大小写如uBlock-Origin。oh-my-dsh 会自动将命令行参数转为小写去匹配目录