背景
目前 lark-cli update 会将 CLI 本体更新与 Lark/Feishu skills 同步行为耦合在一起。
这对希望官方 CLI 和官方 skills 始终保持一致的用户是方便的;但对另一类用户来说会带来风险:他们可能已经使用自己的 skill 管理工具或本地管理流程,例如 Skillshare,来统一管理 AI agent skills。
在这种情况下,如果 lark-cli update 默认联动更新、重写或同步 skills,就可能打乱用户已有的 skill 管理状态,造成双重管理风险。
需求
希望 lark-cli update 支持用户显式选择更新范围。
建议通过后缀参数或 flag 实现,例如:
# 只更新 lark-cli 本体 / npm 包
lark-cli update --cli-only
# 同时更新 lark-cli 本体与官方 Lark/Feishu skills
lark-cli update --with-skills
也可以采用子模式形式:
lark-cli update cli
lark-cli update all
或:
lark-cli update --mode cli
lark-cli update --mode all
期望行为
| 模式 |
期望行为 |
| 仅更新 CLI |
只更新 @larksuite/cli,不安装、不更新、不重写、不同步任何 skills |
| CLI + skills |
更新 @larksuite/cli,并同步更新官方 Lark/Feishu skills |
| 检查模式 |
lark-cli update --check --json 能分别暴露 CLI 与 skills 的更新状态,方便 agent 或脚本判断 |
为什么需要这个能力
用户可能存在两种合理的管理模型:
| 管理模型 |
说明 |
| Lark CLI 统一管理 |
lark-cli 同时负责 CLI 本体和官方 skills |
| 外部工具管理 skills |
lark-cli 只负责 CLI 本体,skills 由 Skillshare 或其他工具/流程管理 |
当前的耦合更新行为会让第二种模型变得脆弱。用户本来可能已经通过外部工具维护了 skill 来源、目录结构、同步状态和元数据,但一次 lark-cli update 就可能改变这些状态。
这对 AI agent 场景尤其敏感,因为 skills 可能同时被 Claude Code、Codex、Cursor 或其他本地 agent 共享。skills 的变化不只是文件更新,还可能影响 agent 路由、上下文注入、元数据追踪和同步状态。
兼容性建议
为了避免破坏已有用户习惯,可以保持当前默认行为不变。
核心诉求是增加一个明确、文档化的“只更新 CLI 本体”的安全路径,让已有 skill 管理体系的用户可以避免被 lark-cli update 意外改动 skills。
相关 issue
这个需求与以下 issue 相关,但关注点不同:
本 issue 只聚焦于:lark-cli update 是否可以让用户选择更新范围。
背景
目前
lark-cli update会将 CLI 本体更新与 Lark/Feishu skills 同步行为耦合在一起。这对希望官方 CLI 和官方 skills 始终保持一致的用户是方便的;但对另一类用户来说会带来风险:他们可能已经使用自己的 skill 管理工具或本地管理流程,例如 Skillshare,来统一管理 AI agent skills。
在这种情况下,如果
lark-cli update默认联动更新、重写或同步 skills,就可能打乱用户已有的 skill 管理状态,造成双重管理风险。需求
希望
lark-cli update支持用户显式选择更新范围。建议通过后缀参数或 flag 实现,例如:
也可以采用子模式形式:
或:
期望行为
@larksuite/cli,不安装、不更新、不重写、不同步任何 skills@larksuite/cli,并同步更新官方 Lark/Feishu skillslark-cli update --check --json能分别暴露 CLI 与 skills 的更新状态,方便 agent 或脚本判断为什么需要这个能力
用户可能存在两种合理的管理模型:
lark-cli同时负责 CLI 本体和官方 skillslark-cli只负责 CLI 本体,skills 由 Skillshare 或其他工具/流程管理当前的耦合更新行为会让第二种模型变得脆弱。用户本来可能已经通过外部工具维护了 skill 来源、目录结构、同步状态和元数据,但一次
lark-cli update就可能改变这些状态。这对 AI agent 场景尤其敏感,因为 skills 可能同时被 Claude Code、Codex、Cursor 或其他本地 agent 共享。skills 的变化不只是文件更新,还可能影响 agent 路由、上下文注入、元数据追踪和同步状态。
兼容性建议
为了避免破坏已有用户习惯,可以保持当前默认行为不变。
核心诉求是增加一个明确、文档化的“只更新 CLI 本体”的安全路径,让已有 skill 管理体系的用户可以避免被
lark-cli update意外改动 skills。相关 issue
这个需求与以下 issue 相关,但关注点不同:
lark-cli update更新 skills 后与npx skills update的元数据兼容问题init/update将 skills 安装到全局还是项目级目录本 issue 只聚焦于:
lark-cli update是否可以让用户选择更新范围。