dbskill 更新机制解读dbs-update 的双渠道同步、旧入口清理与版本契约校验【免费下载链接】dbskilldontbesilent 的商业诊断 Skills项目地址: https://gitcode.com/gh_mirrors/db/dbskilldbskill 是 dontbesilent 的商业诊断 Skills 工具箱由 34 个业务 Skill、2 个兼容入口与 1 个更新入口组成。本文只盯住那个唯一的更新入口dbs-update它负责把本地版本同步到官方最新。读完你能独立判断一次「更新 dbskill」到底动了哪些文件、哪些绝不该碰以及失败后该做什么。定位它在工具箱里的位置dbskill 的组成可以一句话概括34 个业务单元 2 个兼容入口 1 个系统更新入口。前者负责诊断、创作、决策等实际工作dbs-update则是唯一负责「自我维护」的入口不掺任何业务逻辑。它在插件市场里的官方定义如下见 .claude-plugin/marketplace.json字段值说明namedbs-update与目录skills/dbs-update一一对应source./skills/dbs-update插件源码所在目录categoryworkflow-infrastructure归入「工作流基础设施」而非业务诊断类keywordsdbskill, update, upgrade, maintenance, chinese命中「更新 / 升级 / 维护」意图的检索词version3.0.3与仓库根目录 VERSION 完全一致触发方式只有一种口语形态对任意 Agent 说「更新 dbskill」「升级 dbskill」或在收到更新提醒后回复1斜杠命令为/dbs-update。注意1只有在上一条回复确实包含更新提醒时才代表执行没有这个上下文数字不会被解释成更新意图。核心流程更新走的 4 步dbskill 支持两条安装渠道且可能同时存在。dbs-update会先探测实际装了哪条再分别处理避免给同一用户装出两套副本。步骤一识别安装渠道判断逻辑是两条并列线索Claude Code 插件渠道本 Skill 所在路径包含/.claude/plugins/或claude plugin list里出现以dontbesilent-skills结尾的插件Skills CLI 渠道~/.agents/skills/、~/.claude/skills/等目录里有dbs等官方 Skill且不在插件目录下。之所以先分渠道是因为两条渠道的更新命令互不通用——插件用户若误跑 CLI 安装会凭空多出一套本地副本。步骤二按渠道执行同步插件渠道先刷新市场、再逐个更新命令形如claude plugin marketplace update dontbesilent-skills claude plugin update dbsdontbesilent-skillsSkills CLI 渠道则走一条幂等的重同步命令npx -y skills add dontbesilent2025/dbskill -g --all这里的设计意图值得点破「安装」与「更新」走的是同一条同步链路。-g表示全局安装--all表示拉取全部正式 Skill。把更新实现成「重新同步」本地就永远和官方仓库一致命令可反复执行而不产生副作用。两种渠道都检测不到时兜底执行这条 CLI 命令。步骤三清理已下线的旧入口官方历史版本里有三个 Skill 已退役dbs-hook、dbs-xhs-title、dbs-agent-migration。名单连同各自的官方历史版本指纹记录在本 Skill 的references/retired-skills.json中。清理规则极其克制——只移除能确认来自官方的副本插件渠道按名单逐个claude plugin uninstall本地目录则运行scripts/cleanup_retired_skills.py它只删失效链接或指向官方旧版本的链接与官方旧版完全一致的目录会被移到~/.dbs/retired-skills/时间/备份用户改过或同名的自有 Skill 一律保留。环境没有 Python 时跳过脚本只在回复里列出名单请用户自查。步骤四标记时间并确认结果命令成功后会写入一个时间戳避免当前对话仍加载着旧 Skill 时反复提醒mkdir -p $HOME/.dbs date %s $HOME/.dbs/update_check_at随后按渠道提醒重载插件渠道提示运行/reload-plugins其余渠道提示新建一次对话。失败时只回一句原因并把完整终端日志藏起来除非用户主动索要。安全边界5 条硬规则更新会改写文件所以边界是这个 Skill 真正的安全核心。skills/dbs-update/SKILL.md 用五条规则钉死了范围边界说明只同步官方仓库仅对齐dontbesilent2025/dbskill不从任何第三方源拉取保留~/.dbs/用户数据存档、报告、决策记录全部原样保留不覆盖不动其他 Skill用户自行安装的 Skill 不在同步范围清理仅限官方副本下线旧入口只处理能确认官方的用户改过的或同名的自有项保留不建后台任务不创建定时任务或 Agent Hook更新是一次性显式动作其中「保留~/.dbs/」影响最大。dbskill 的dbs-save、dbs-restore、dbs-decision会把诊断状态与决策长期沉淀到本地这是用户跨对话积累下来的资产。更新只覆盖 Skill 代码本身绝不触碰这些数据。README.md 的「更新与帮助」小节同样写明这一承诺更新会同步官方 dbskill保留~/.dbs/里的存档和记录并自动清理已经下线的旧 Skill。把数据安全写成显式承诺而不是隐含假设正是新手最该先确认的一条。标准话术成功与失败分别怎么回为了体验一致Skill 规定了两套固定模板可直接照抄。成功时dbskill 已更新完成{更新的渠道}。当前对话如果还没有读取到新能力{插件渠道运行/reload-plugins其他渠道新建一次对话}后即可使用。若顺带清理了旧入口追加一句已清理下线的旧入口{名称与位置}。{有备份时原文件备份在{备份目录}。}{有保留项时{路径}与官方版本不一致已保留。}失败时dbskill 没有更新完成{简短原因}。处理完 {权限或网络问题} 后再说一次「更新 dbskill」。这套话术的设计意图可以拆成三点原因简短化只给权限或网络两类不堆日志、处理对象明确化指向具体该修的那件事、恢复动作具体化再说一次「更新 dbskill」即可重试。用户不需要读终端只需要知道下一步。源码级兜底发布侧靠什么保证可靠用户侧只说一句话可靠却建立在发布侧的两道校验脚本之上。第一道是 tools/check-plugin-update-contract.py专门校验「插件可升级的版本契约」VERSION必须符合MAJOR.MINOR.PATCH三段式市场里每个插件的version必须与VERSION相等所有.claude-plugin/plugin.json清单里的version不得与市场版本冲突否则会覆盖市场版本导致升级错乱加--release参数时会对比上一个发布 tag若某插件版本与上一发布相同Claude Code 会直接跳过更新。最后一条解释了为什么「每次升级都必须换版本号」——否则 Agent 侧的更新会因版本没变而静默失效。第二道是 tools/check-release-versions.py它把版本一致性从单一市场扩展到全部公开入口VERSION、市场metadata.version、README 及所有语言翻译版的 Version Badge、主入口skills/dbs/SKILL.md里的DBS_LOCAL_VERSION、以及UPDATE.json的version与notice20~80 字符且无首尾空白必须全部指向同一个值。当前仓库VERSION为3.0.3市场里全部插件的版本号也都是3.0.3正是这套契约一次通过的落地结果。两道脚本合起来意味着用户看到的是「更新 dbskill」这一句话背后是「版本号必变、多入口一致、契约可自动校验」的完整发布体系。使用姿势触发、误用与交接容易踩错的点用正误对照看得最清楚场景正确做法只问版本 / 更新内容 / 要不要更新先回答问题不执行命令明确要检查并希望实际同步按本 Skill 走更新流程更新提醒后回复1视为明确要求直接执行不再二次确认想用npx skills update禁用。该命令会连带更新用户装的其他 Skill越出边界关于「不二次确认」只要用户说出了明确的更新指令Agent 直接进入执行不反问「你确定吗」。唯一例外是宿主权限——若需要 Shell 授权由用户在宿主权限窗口里自行决定。路由侧由主入口/dbs完成分工skills/dbs/SKILL.md 明确「/dbs-update只在用户明确要求更新或紧接更新提醒回复1时入选」。也就是说无论你走/dbs主入口还是直接敲/dbs-update最终都会汇入同一条更新流程——主入口只识别意图具体执行全部交给dbs-update。docs/新手入门.md 的「怎样更新」一节也是同一套口径安装后直接对当前 Agent 说「更新 dbskill」即可无需复制任何命令。收尾遵循「不替用户预设下一站」的原则更新任务本身到此结束。新能力加载完成后把球交还给主入口/dbs由它读取你的最新目标继续路由到该处理的业务 Skill。小结单一职责只做官方仓库同步与下线入口清理绝不碰其他 Skill 与用户数据。双渠道意识先探测实际装了哪条渠道分别同步避免同一用户出现两套副本。数据安全优先~/.dbs/的存档、报告、决策记录被显式承诺为不可触碰。命令有取舍用幂等的skills add重同步明确禁用会波及其他 Skill 的skills update。底层有契约版本号必变、多入口一致、契约可脚本校验更新链路本身可靠。一句话记住想升级就直说「更新 dbskill」剩下交给dbs-update更新完重载一次再回/dbs接着干活。【免费下载链接】dbskilldontbesilent 的商业诊断 Skills项目地址: https://gitcode.com/gh_mirrors/db/dbskill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/11/5 1:24:32 · 阅读 1.2k dbskill 更新机制解读：dbs-update 的双渠道同步、旧入口清理与版本契约校验
dbskill 更新机制解读dbs-update 的双渠道同步、旧入口清理与版本契约校验【免费下载链接】dbskilldontbesilent 的商业诊断 Skills项目地址: https://gitcode.com/gh_mirrors/db/dbskilldbskill 是 dontbesilent 的商业诊断 Skills 工具箱由 34 个业务 Skill、2 个兼容入口与 1 个更新入口组成。本文只盯住那个唯一的更新入口dbs-update它负责把本地版本同步到官方最新。读完你能独立判断一次「更新 dbskill」到底动了哪些文件、哪些绝不该碰以及失败后该做什么。定位它在工具箱里的位置dbskill 的组成可以一句话概括34 个业务单元 2 个兼容入口 1 个系统更新入口。前者负责诊断、创作、决策等实际工作dbs-update则是唯一负责「自我维护」的入口不掺任何业务逻辑。它在插件市场里的官方定义如下见 .claude-plugin/marketplace.json字段值说明namedbs-update与目录skills/dbs-update一一对应source./skills/dbs-update插件源码所在目录categoryworkflow-infrastructure归入「工作流基础设施」而非业务诊断类keywordsdbskill, update, upgrade, maintenance, chinese命中「更新 / 升级 / 维护」意图的检索词version3.0.3与仓库根目录 VERSION 完全一致触发方式只有一种口语形态对任意 Agent 说「更新 dbskill」「升级 dbskill」或在收到更新提醒后回复1斜杠命令为/dbs-update。注意1只有在上一条回复确实包含更新提醒时才代表执行没有这个上下文数字不会被解释成更新意图。核心流程更新走的 4 步dbskill 支持两条安装渠道且可能同时存在。dbs-update会先探测实际装了哪条再分别处理避免给同一用户装出两套副本。步骤一识别安装渠道判断逻辑是两条并列线索Claude Code 插件渠道本 Skill 所在路径包含/.claude/plugins/或claude plugin list里出现以dontbesilent-skills结尾的插件Skills CLI 渠道~/.agents/skills/、~/.claude/skills/等目录里有dbs等官方 Skill且不在插件目录下。之所以先分渠道是因为两条渠道的更新命令互不通用——插件用户若误跑 CLI 安装会凭空多出一套本地副本。步骤二按渠道执行同步插件渠道先刷新市场、再逐个更新命令形如claude plugin marketplace update dontbesilent-skills claude plugin update dbsdontbesilent-skillsSkills CLI 渠道则走一条幂等的重同步命令npx -y skills add dontbesilent2025/dbskill -g --all这里的设计意图值得点破「安装」与「更新」走的是同一条同步链路。-g表示全局安装--all表示拉取全部正式 Skill。把更新实现成「重新同步」本地就永远和官方仓库一致命令可反复执行而不产生副作用。两种渠道都检测不到时兜底执行这条 CLI 命令。步骤三清理已下线的旧入口官方历史版本里有三个 Skill 已退役dbs-hook、dbs-xhs-title、dbs-agent-migration。名单连同各自的官方历史版本指纹记录在本 Skill 的references/retired-skills.json中。清理规则极其克制——只移除能确认来自官方的副本插件渠道按名单逐个claude plugin uninstall本地目录则运行scripts/cleanup_retired_skills.py它只删失效链接或指向官方旧版本的链接与官方旧版完全一致的目录会被移到~/.dbs/retired-skills/时间/备份用户改过或同名的自有 Skill 一律保留。环境没有 Python 时跳过脚本只在回复里列出名单请用户自查。步骤四标记时间并确认结果命令成功后会写入一个时间戳避免当前对话仍加载着旧 Skill 时反复提醒mkdir -p $HOME/.dbs date %s $HOME/.dbs/update_check_at随后按渠道提醒重载插件渠道提示运行/reload-plugins其余渠道提示新建一次对话。失败时只回一句原因并把完整终端日志藏起来除非用户主动索要。安全边界5 条硬规则更新会改写文件所以边界是这个 Skill 真正的安全核心。skills/dbs-update/SKILL.md 用五条规则钉死了范围边界说明只同步官方仓库仅对齐dontbesilent2025/dbskill不从任何第三方源拉取保留~/.dbs/用户数据存档、报告、决策记录全部原样保留不覆盖不动其他 Skill用户自行安装的 Skill 不在同步范围清理仅限官方副本下线旧入口只处理能确认官方的用户改过的或同名的自有项保留不建后台任务不创建定时任务或 Agent Hook更新是一次性显式动作其中「保留~/.dbs/」影响最大。dbskill 的dbs-save、dbs-restore、dbs-decision会把诊断状态与决策长期沉淀到本地这是用户跨对话积累下来的资产。更新只覆盖 Skill 代码本身绝不触碰这些数据。README.md 的「更新与帮助」小节同样写明这一承诺更新会同步官方 dbskill保留~/.dbs/里的存档和记录并自动清理已经下线的旧 Skill。把数据安全写成显式承诺而不是隐含假设正是新手最该先确认的一条。标准话术成功与失败分别怎么回为了体验一致Skill 规定了两套固定模板可直接照抄。成功时dbskill 已更新完成{更新的渠道}。当前对话如果还没有读取到新能力{插件渠道运行/reload-plugins其他渠道新建一次对话}后即可使用。若顺带清理了旧入口追加一句已清理下线的旧入口{名称与位置}。{有备份时原文件备份在{备份目录}。}{有保留项时{路径}与官方版本不一致已保留。}失败时dbskill 没有更新完成{简短原因}。处理完 {权限或网络问题} 后再说一次「更新 dbskill」。这套话术的设计意图可以拆成三点原因简短化只给权限或网络两类不堆日志、处理对象明确化指向具体该修的那件事、恢复动作具体化再说一次「更新 dbskill」即可重试。用户不需要读终端只需要知道下一步。源码级兜底发布侧靠什么保证可靠用户侧只说一句话可靠却建立在发布侧的两道校验脚本之上。第一道是 tools/check-plugin-update-contract.py专门校验「插件可升级的版本契约」VERSION必须符合MAJOR.MINOR.PATCH三段式市场里每个插件的version必须与VERSION相等所有.claude-plugin/plugin.json清单里的version不得与市场版本冲突否则会覆盖市场版本导致升级错乱加--release参数时会对比上一个发布 tag若某插件版本与上一发布相同Claude Code 会直接跳过更新。最后一条解释了为什么「每次升级都必须换版本号」——否则 Agent 侧的更新会因版本没变而静默失效。第二道是 tools/check-release-versions.py它把版本一致性从单一市场扩展到全部公开入口VERSION、市场metadata.version、README 及所有语言翻译版的 Version Badge、主入口skills/dbs/SKILL.md里的DBS_LOCAL_VERSION、以及UPDATE.json的version与notice20~80 字符且无首尾空白必须全部指向同一个值。当前仓库VERSION为3.0.3市场里全部插件的版本号也都是3.0.3正是这套契约一次通过的落地结果。两道脚本合起来意味着用户看到的是「更新 dbskill」这一句话背后是「版本号必变、多入口一致、契约可自动校验」的完整发布体系。使用姿势触发、误用与交接容易踩错的点用正误对照看得最清楚场景正确做法只问版本 / 更新内容 / 要不要更新先回答问题不执行命令明确要检查并希望实际同步按本 Skill 走更新流程更新提醒后回复1视为明确要求直接执行不再二次确认想用npx skills update禁用。该命令会连带更新用户装的其他 Skill越出边界关于「不二次确认」只要用户说出了明确的更新指令Agent 直接进入执行不反问「你确定吗」。唯一例外是宿主权限——若需要 Shell 授权由用户在宿主权限窗口里自行决定。路由侧由主入口/dbs完成分工skills/dbs/SKILL.md 明确「/dbs-update只在用户明确要求更新或紧接更新提醒回复1时入选」。也就是说无论你走/dbs主入口还是直接敲/dbs-update最终都会汇入同一条更新流程——主入口只识别意图具体执行全部交给dbs-update。docs/新手入门.md 的「怎样更新」一节也是同一套口径安装后直接对当前 Agent 说「更新 dbskill」即可无需复制任何命令。收尾遵循「不替用户预设下一站」的原则更新任务本身到此结束。新能力加载完成后把球交还给主入口/dbs由它读取你的最新目标继续路由到该处理的业务 Skill。小结单一职责只做官方仓库同步与下线入口清理绝不碰其他 Skill 与用户数据。双渠道意识先探测实际装了哪条渠道分别同步避免同一用户出现两套副本。数据安全优先~/.dbs/的存档、报告、决策记录被显式承诺为不可触碰。命令有取舍用幂等的skills add重同步明确禁用会波及其他 Skill 的skills update。底层有契约版本号必变、多入口一致、契约可脚本校验更新链路本身可靠。一句话记住想升级就直说「更新 dbskill」剩下交给dbs-update更新完重载一次再回/dbs接着干活。【免费下载链接】dbskilldontbesilent 的商业诊断 Skills项目地址: https://gitcode.com/gh_mirrors/db/dbskill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考