skill-flow 1.0.2 → 1.0.3

package/docs/PRD/renew/PRD-0.0.2.md

@@ -1,705 +0,0 @@
-我又做了一轮核查，结论比你母版里更明确了：
-
-第一，**MVP 不应把所有渠道都当成“同一种目录”处理**。Claude Code、OpenCode、Codex、OpenClaw 对 skills 的发现路径与行为并不一致，尤其 OpenClaw 对 realpath 有约束，Codex 明确支持 symlink，OpenCode 会同时扫 `.opencode/skills`、`.claude/skills`、`.agents/skills`，Claude Code 还有个人级、项目级和嵌套发现。产品层必须把“渠道”定义为 **adapter**，而不是一个路径字符串。([Claude][1])
-
-第二，**`manifest + lock` 必须是强制设计，不要允许“无状态运行”**。ClawHub 会把安装状态记到 `.clawhub/lock.json`，Vercel 的 `npx skills` 也依赖 lock file 与 `skillFolderHash` 做更新判断；这些现成实践已经说明，skills 管理器一旦涉及多来源、多渠道、多策略分发，没有锁定层就很难保证更新、回滚和恢复安装。([OpenClaw][2])
-
-第三，**source 层要从第一天就按插件接口建模**。Git 仓库是 MVP 主路径，但公开生态已经同时存在 ClawHub registry 工作流，以及 `/.well-known/skills/index.json` 这类 URL 发现协议；如果 source 抽象不先立住，后面每加一个来源都要改核心模型。([OpenClaw][2])
-
-第四，**技术栈最稳的选择是 TypeScript + Node.js 22 + oclif + Ink**。原因不是“我偏好 JS”，而是这条链路和你要接入的生态最接近：现有 `npx skills`、ClawHub CLI、OpenClaw 周边工作流都天然贴近 Node 侧；而你的 `config` 是树状多选 TUI，Ink 比传统 flag parser 更适合。Node 22 目前仍处在长期支持窗口内；oclif 本身就是面向可扩展 CLI 的框架；Ink 是 React 风格的 CLI UI；Zod 适合做 manifest/lock/schema 校验；simple-git 适合包一层 git 操作；Vitest 则足够快、适合 CLI 工程。([Node.js][3])
-
-下面我直接按你上传 PRD 的骨架，给出一版**增强版 PRD v0.2**。
-
----
-
-# skill-flow PRD v0.2
-
-## 文档信息
-
-* 产品名称：`skill-flow`
-* 启动命令：`skill-flow`
-* MVP 支持平台：macOS
-* 数据根目录：`~/.skillflow/`（以下简称 `SM_HOME`）
-* 产品定位：统一管理多来源 Agent Skills，完成下载、解析、索引、锁定、更新、分发、卸载与诊断。
-
----
-
-## 背景与本轮调研结论
-
-当前 Skills 生态在“skill 目录结构”上已经高度收敛：一个 skill 是一个目录，最小单元是 `SKILL.md`，并带 `name`、`description` 等 frontmatter；可选附带 `scripts/`、`references/`、`assets/` 等内容。OpenCode、Codex、Claude Code 都沿用这一模型，OpenCode 甚至明确要求 `name` 与目录名匹配，并给出命名 regex。([Agent Skills][4])
-
-但“本地发现路径”并没有统一。Claude Code 支持 `~/.claude/skills` 与项目级 `.claude/skills`，并支持嵌套自动发现；OpenCode 同时支持 `.opencode/skills`、`.claude/skills`、`.agents/skills` 的全局与项目路径，并会从当前目录向上遍历到 git worktree；Codex 以 `$HOME/.agents/skills`、`$REPO_ROOT/.agents/skills` 为正式发现点，并明确支持 symlink；OpenClaw 则区分 bundled、`~/.openclaw/skills`、`<workspace>/skills`，还允许 `skills.load.extraDirs`，但对 realpath 有边界校验。([Claude][1])
-
-这意味着 `skill-flow` 的核心不是“文件搬运”，而是：
-
-**Source Resolver → Skill Indexer → Channel Projector**
-
-也就是：
-从多来源拿到原始内容，解析为 skill leaf，再按不同渠道的规则安全地投影出去。这个定义与 Vercel `npx skills` 的“canonical copy + symlink/copy dispatch”思路是一致的，但你的产品需要更强的 source 分组、两层树状选择、以及更严格的渠道差异化策略。([GitHub][5])
-
----
-
-## 本轮拍板的关键产品决策
-
-### 1. MVP 作用域
-
-MVP 只支持 **global scope**，不做通用 project scope；唯一例外是 OpenClaw，因为它的官方模型本来就高度依赖 workspace。也就是说：
-
-* Claude Code：先支持 `~/.claude/skills`
-* OpenCode：先支持 `~/.config/opencode/skills`
-* Codex：先支持 `~/.agents/skills`
-* 通用：支持 `~/.agents/skills`
-* OpenClaw：支持 `~/.openclaw/skills` 与 `<workspace>/skills`
-
-这样可以避开 Codex trusted project config、OpenCode/Codex/Claude 的 repo 向上遍历等复杂度，把第一版做成“个人级 skills 管理器”。([OpenAI Developers][6])
-
-### 2. OpenClaw 默认 copy，不走 symlink
-
-OpenClaw 渠道默认采用 `copy` 策略，把 skill 真实落到 `<workspace>/skills` 或 `~/.openclaw/skills`。原因是官方文档明确说明其 discovery 仅接受 realpath 落在配置 root 内的 skill root / `SKILL.md`，这会让“从 `SM_HOME` 跨目录 symlink 进 workspace”的方案存在高概率兼容问题。([OpenClaw][7])
-
-### 3. Codex 的正式默认渠道是 `~/.agents/skills`
-
-基于当前官方文档，Codex 的正式 user-level skills 目录是 `$HOME/.agents/skills`，并且官方明确说明会跟随 symlink 扫描。因此 MVP 不把 `~/.codex/skills` 作为正式 channel 暴露；若用户确有历史目录习惯，只通过 advanced config 自定义 path override。([OpenAI Developers][6])
-
-### 4. 必须有 `manifest.json` 与 `lock.json`
-
-* `manifest.json` 记录用户意图：sources、命名策略、channel 绑定关系
-* `lock.json` 记录解析结果：source snapshot、skill leaf、deployment 结果
-
-不提供“纯扫描、纯临时分发”的无状态模式。([OpenClaw][2])
-
-### 5. `uninstall` 与 `config` 分责
-
-* `config` 负责“启用/停用 skill 对某个 channel 的投影”
-* `uninstall` 负责“删除 source、索引和相关投影”
-
-也就是说，“某个 channel 不想再用这个 skill”不是 uninstall，而是 config 的 disable 行为。
-
----
-
-## 产品定义
-
-`skill-flow` 是一个面向 Agent Skills 生态的命令行包管理器。它从 Git 仓库、ClawHub、未来的 well-known discovery URL 等来源拉取 skills，统一存入 `SM_HOME/source`，扫描出合法的 skill leaf，建立本地索引与锁定状态，再按用户选择分发到不同的 agent 渠道目录。技能最终以目录形式暴露给目标 agent，满足其对 `SKILL.md` 的发现要求。([Agent Skills][4])
-
----
-
-## 目标、非目标与成功指标
-
-### 目标（MVP）
-
-1. 支持 Git source 的添加、扫描、更新、卸载。
-2. 支持 ClawHub source 的添加、更新与锁定。
-3. 建立 Source → Skill 的两层索引模型。
-4. 提供树状多选 TUI 完成渠道配置。
-5. 默认分发到 Claude Code / OpenCode / Codex / OpenClaw / `.agents/skills`。
-6. 对每个渠道应用最合适的策略：`symlink` / `copy` / 配置注入。
-7. 提供 `doctor` 检查路径、冲突、损坏链接和安全风险。
-
-### 非目标（MVP）
-
-1. 不执行 skill 内的脚本。
-2. 不改写 skill 内容。
-3. 不做 GUI。
-4. 不做组织级远程同步。
-5. 不做通用 project-scope 管理。
-
-### 成功指标
-
-* 首次安装并在 2 个渠道可用的时间小于 3 分钟。
-* `update --all` 后，无需手工修复即可完成大多数 channel 的一致重投影。
-* 任一次安装/更新/卸载都可通过 state 文件与日志回溯。
-* 失败时不留下半配置状态。
-
----
-
-## 领域模型与系统边界
-
-### 核心实体
-
-**Source**
-一个可更新的上游来源。
-示例：Git 仓库、ClawHub slug、well-known skills URL。
-
-**SourceSnapshot**
-某个 source 的本地解析快照。
-Git 用 commit SHA；ClawHub 用 version/tag；well-known 用 index hash / etag。([OpenClaw][2])
-
-**SkillLeaf**
-最终可安装的 skill 单元。一个 leaf 必须能映射到一个合法 skill root，即目录内存在 `SKILL.md` 且 `name`、`description` 可解析。([Agent Skills][4])
-
-**Channel**
-一个目标 agent 适配器，不只是路径，还包括发现规则、优先级、以及支持的分发策略。
-
-**Deployment**
-一次把若干 leaf 投影到某个 channel 的结果。包含 strategy、目标路径、状态、时间戳。
-
-### 系统边界
-
-`skill-flow` 只负责：
-
-* 获取
-* 校验
-* 索引
-* 锁定
-* 分发
-* 更新
-* 卸载
-* 诊断
-
-它不负责运行 skill，不负责替代 agent 的 skill loader，也不负责对脚本做沙箱。官方文档已经把第三方 skills 视作潜在不可信输入，因此本工具只做静态保护与分发安全，不做运行时安全承诺。([OpenClaw][7])
-
----
-
-## 核心命令设计
-
-```bash
-skill-flow add <source>
-skill-flow search <query>
-skill-flow list
-skill-flow config
-skill-flow update [--all | <sourceId>]
-skill-flow uninstall [<sourceId>...]
-skill-flow doctor
-```
-
-### `add`
-
-作用：新增一个 source，并生成索引。
-流程：
-
-1. 解析 source 类型
-2. 下载到 `SM_HOME/source/<sourceKey>`
-3. 扫描合法 skill leaf
-4. 更新 `manifest.json` / `lock.json`
-5. 在 `SM_HOME/skills` 建立 canonical entries
-
-### `search`
-
-MVP 搜索来源：
-
-* ClawHub：一级支持
-* GitHub：支持 repo lookup 与 repo search
-* P1：well-known URL discovery
-
-ClawHub 已经提供 registry/CLI 工作流；well-known discovery 也已有公开文档与 Mintlify 落地，因此 source adapter 需要预留统一接口。([OpenClaw][2])
-
-### `config`
-
-交互分三屏：
-
-**第一屏：选择渠道**
-展示已检测到的渠道与目标路径。
-
-**第二屏：选择 Source / Skill 树**
-
-* 一级：source root
-* 二级：skill leaf
-* Space：选中
-* Tab：展开/折叠
-* Enter：确认
-* 一级节点三态：未选 / 部分 / 全选
-
-**第三屏：应用确认**
-显示：
-
-* 目标 channel
-* 选中 leaf 数量
-* 将创建的 symlink 数
-* 将复制的目录数
-* 冲突数
-* 风险提示数
-
-### `uninstall`
-
-按 source 粒度删除：
-
-* `SM_HOME/source/<sourceKey>`
-* `SM_HOME/skills/<sourceKey>`
-* 所有关联 deployments
-* manifest / lock 中相关条目
-
-### `doctor`
-
-至少检查：
-
-* 目标渠道路径是否存在
-* symlink 是否断裂
-* OpenClaw channel 是否存在 root 外 realpath 风险
-* 同名 skill 冲突
-* lock 与实际磁盘是否漂移
-* 当前 source 是否有可更新项
-
----
-
-## Source 模型与获取策略
-
-### Source Adapter 列表
-
-#### A. Git Adapter（MVP 必做）
-
-支持：
-
-* `owner/repo`
-* `https://...git`
-* `git@...`
-* 本地 git 路径
-
-落地策略：
-
-* 原始仓库以完整工作区形式存入 `SM_HOME/source/git/<sourceKey>`
-* 更新优先用本地 `git fetch/pull`
-* 对 GitHub 源可用 REST Trees API 做轻量更新检查或远程结构预览；GitHub 官方也明确 Trees API 用于树层级对象，Contents API 递归获取目录时有 1000 文件上限，超过时应改用 Trees API。([GitHub Docs][8])
-
-#### B. ClawHub Adapter（MVP 必做）
-
-支持：
-
-* `clawhub:<slug>`
-* `clawhub:<slug>@<version>`
-* 搜索后安装
-
-推荐交付方式：
-
-* MVP 优先 shell-out 调用 `clawhub`
-* 同步吸收 `.clawhub/lock.json` 中的版本信息到本工具 lock
-
-理由是 ClawHub 官方已经有 install / update / sync / lockfile 语义，直接复用能更快上线。([OpenClaw][2])
-
-#### C. Well-known Skills Adapter（P1 预留）
-
-支持：
-
-* 任意 URL
-* 自动探测 `/.well-known/skills/index.json`
-* 下载列出的 skill 文件集
-
-Mintlify 已公开支持这一协议，因此这不是“未来幻想”，而是很快会变成真实来源类型。([Mintlify][9])
-
----
-
-## Skill 解析与索引规则
-
-### Skill 判定
-
-一个目录被视为合法 skill，当且仅当：
-
-1. 存在 `SKILL.md`
-2. frontmatter 可解析
-3. `name` 存在
-4. `description` 存在
-5. 在标准模式下，`name` 与目录名匹配
-
-这与 Agent Skills 规范、OpenCode 规则以及 Codex 的技能格式要求一致。([Agent Skills][4])
-
-### 解析结果字段
-
-每个 leaf 至少保存：
-
-* `skillId`
-* `sourceId`
-* `name`
-* `description`
-* `relativeRoot`
-* `hasScripts`
-* `hasReferences`
-* `hasAssets`
-* `contentHash`
-* `riskFlags[]`
-
-### 索引结构
-
-UI 上统一呈现为两层：
-
-* 一级：Source
-* 二级：SkillLeaf
-
-磁盘上分三层：
-
-* `source/`：原始来源
-* `skills/`：canonical entries
-* `state/`：manifest/lock/history
-
----
-
-## Channel 适配与分发策略
-
-### Claude Code
-
-默认目标：`~/.claude/skills`。
-策略：**单 skill symlink**。
-
-原因：Claude Code 官方支持个人/项目路径和嵌套发现；但保持 `~/.claude/skills` 为真实目录更稳，避免破坏其他共存文件；同时历史上存在 `/skills` 对 symlink 呈现不一致的问题，所以 `doctor` 需要给出 UX 提示，并允许高级模式切换为 copy。([Claude][1])
-
-### OpenCode
-
-默认目标：`~/.config/opencode/skills`。
-策略：**symlink**。
-
-OpenCode 官方同时兼容 `.claude/skills` 与 `.agents/skills`，但为避免“一个 channel 影响另一个 channel”的隐式耦合，MVP 仍把 OpenCode 作为独立目标目录处理。([OpenCode][10])
-
-### Codex
-
-默认目标：`~/.agents/skills`。
-策略：**symlink**。
-
-Codex 官方明确支持 symlink，并允许通过 `~/.codex/config.toml` 中的 `[[skills.config]]` 对具体 skill 路径做禁用；这给后续的“高级禁用策略”留出了空间，但 MVP 不修改 Codex config，只做文件级分发。([OpenAI Developers][6])
-
-### OpenClaw
-
-默认目标：
-
-* 首选：`<workspace>/skills`
-* 备选：`~/.openclaw/skills`
-
-默认策略：**copy**。
-
-OpenClaw workspace 默认是 `~/.openclaw/workspace`，官方配置项是 `agents.defaults.workspace`；且 skill discovery 要求 realpath 留在 root 内。由于这与中心化 `SM_HOME` + symlink 方案天然冲突，MVP 对 OpenClaw 不做中心化链接分发，直接 copy。([OpenClaw][11])
-
-### 通用 `.agents/skills`
-
-默认目标：`~/.agents/skills`。
-策略：**symlink**。
-
-这个渠道本身就能被 Codex 与 OpenCode 共同消费，因此可作为默认共享投影点。([OpenCode][10])
-
----
-
-## 数据存储与状态文件
-
-### 目录结构
-
-```text
-~/.skillflow/
-  source/
-    git/
-      <sourceKey>/
-    clawhub/
-      <sourceKey>/
-    wellknown/
-      <sourceKey>/
-  skills/
-    <sourceKey>/
-      <skillName>/ -> ../../source/...
-  state/
-    manifest.json
-    lock.json
-    channels.json
-    history.ndjson
-  cache/
-  tmp/
-  logs/
-```
-
-### `manifest.json`
-
-记录用户意图：
-
-* sources[]
-* naming policy
-* channel selections
-* per-channel strategy override（advanced only）
-
-### `lock.json`
-
-记录解析结果：
-
-* schemaVersion
-* source snapshots
-* discovered skill leafs
-* deployments
-* content hashes
-* last update times
-
-### `channels.json`
-
-记录本机探测与用户 override：
-
-* channel id
-* detected path
-* path source
-* available strategies
-* health status
-
-### `history.ndjson`
-
-记录审计事件：
-
-* `add`
-* `scan`
-* `config-apply`
-* `update`
-* `uninstall`
-* `doctor-warning`
-
----
-
-## 冲突、错误与原子性
-
-### 冲突规则
-
-1. **同 channel 同名冲突**
-   默认阻止，要求用户二选一。
-
-2. **目标路径已有非 skill-flow 文件**
-   默认不接管，标记 `foreign-existing`。
-
-3. **source 内同名 skill**
-   扫描时直接判定 source 非法，需要用户手工选择子路径或忽略。
-
-### 原子写入
-
-* state 文件写入：`tmp -> fsync -> rename`
-* copy 分发：先复制到临时目录，再原子移动
-* symlink 分发：先校验目标，再替换 link
-* 若 apply 过程中失败，不写 lock 的已完成状态
-
----
-
-## 安全策略
-
-第三方 skills 应被视为不可信输入。Claude Code 与 OpenClaw 官方文档都明确提示需要像安装软件一样审查来源，尤其警惕技能中包含的脚本、外部依赖和秘密注入。([Claude][1])
-
-MVP 安全要求：
-
-1. **永不执行脚本**
-   只扫描，不运行 `scripts/`。
-
-2. **静态校验**
-   校验 `SKILL.md`、name、description、目录名匹配关系。
-
-3. **路径约束**
-   校验任何 target path、link target、copy source 的 realpath。
-
-4. **风险标记**
-
-* `has-scripts`
-* `invalid-frontmatter`
-* `name-dir-mismatch`
-* `external-symlink`
-* `foreign-existing`
-* `openclaw-root-risk`
-
-5. **安装确认**
-   对非本地来源默认二次确认；`--yes` 为显式跳过。
-
-6. **diff 审计**
-   `list --diff` 或 `update --diff` 展示变更摘要。
-
----
-
-## 技术栈
-
-### 推荐主栈
-
-**语言与运行时**
-
-* TypeScript 5.x
-* Node.js 22 LTS
-* 包管理：pnpm
-
-选择理由：Node 22 仍处于长期支持窗口；而 oclif、Ink、simple-git、Vitest 这套 CLI 工具链在 Node 侧最成熟。([Node.js][3])
-
-**CLI 框架**
-
-* `oclif`
-
-理由：`skill-flow` 不是单文件工具，而是带子命令、可扩展、未来可能开放 source/channel 插件接口的 CLI；oclif 官方就是为可扩展 CLI 设计的。([oclif.github.io][12])
-
-**TUI 层**
-
-* `Ink`
-
-理由：`config` 是树状多选 TUI，Ink 提供 React 风格组件模型与 terminal flexbox 布局，明显比传统 prompt 库更适合复杂交互。([GitHub][13])
-
-**Schema / 配置校验**
-
-* `Zod`
-
-理由：manifest、lock、channel config、source adapter response 都是非可信输入，Zod 的 TypeScript-first schema 模式很适合做运行时校验与类型收敛。([Zod][14])
-
-**Git 操作**
-
-* 首选：系统 `git` 二进制
-* 封装层：`simple-git`
-
-理由：Git 是系统真相源；simple-git 适合作为轻量包装层，不重造 git 协议。([npm][15])
-
-**YAML / frontmatter 解析**
-
-* `yaml` 或等价 YAML parser
-* frontmatter 解析采用轻薄封装，自定义约束逻辑放在应用层
-
-理由：skill 格式的关键不是 Markdown 渲染，而是 frontmatter 的强校验。([npm][16])
-
-**测试**
-
-* `Vitest`：单元与集成测试
-* `tmpdir` 驱动的文件系统测试
-* fixture repos / fixture skills
-
-Vitest 适合 Node/TS 项目，速度快，足够覆盖 CLI 与 parser 工程。([Vitest][17])
-
-**发布与 CI**
-
-* GitHub Actions
-* npm 发布
-* Homebrew Tap（P1）
-
-GitHub 官方文档已提供 Node 项目的 build/test 与 package publishing 工作流，因此这条链路成本最低。([GitHub Docs][18])
-
-### 工程分层
-
-```text
-src/
-  commands/          # oclif commands
-  tui/               # Ink screens / widgets
-  domain/            # Source / Skill / Channel / Deployment models
-  adapters/
-    source/
-    channel/
-  services/
-    scan/
-    install/
-    update/
-    deploy/
-    doctor/
-  state/
-    manifest/
-    lock/
-    migration/
-  utils/
-```
-
-### 插件接口
-
-先做**内建插件机制**，不做第三方运行时插件安装。
-
-```ts
-interface SourceAdapter {
-  kind: "git" | "clawhub" | "wellknown";
-  probe(input: string): boolean;
-  resolve(input: string): Promise<ResolvedSource>;
-  fetch(source: ResolvedSource, ctx: FetchContext): Promise<SourceSnapshot>;
-  update(snapshot: SourceSnapshot, ctx: UpdateContext): Promise<SourceSnapshot>;
-  scan(snapshot: SourceSnapshot): Promise<DiscoveredSkill[]>;
-}
-```
-
-```ts
-interface ChannelAdapter {
-  kind: "claude" | "opencode" | "codex" | "openclaw" | "agents";
-  detect(ctx: DetectContext): Promise<DetectedChannel | null>;
-  plan(skills: SkillLeaf[], channel: DetectedChannel): Promise<DeploymentPlan>;
-  apply(plan: DeploymentPlan): Promise<DeploymentResult>;
-  diagnose(channel: DetectedChannel): Promise<DoctorFinding[]>;
-}
-```
-
----
-
-## 测试策略
-
-### 单元测试
-
-覆盖：
-
-* source locator parser
-* frontmatter validator
-* skill scanner
-* naming / conflict rules
-* lock migration
-
-### 集成测试
-
-用 fixture repo / fixture channel dirs 做黑盒测试：
-
-1. add git source
-2. config apply to Claude / OpenCode / Codex
-3. OpenClaw copy deployment
-4. update with changed leaf
-5. uninstall rollback
-6. broken symlink detection
-
-### 回归测试
-
-重点盯三个高风险点：
-
-* OpenClaw realpath
-* Claude symlink UX
-* 同名 skill 冲突恢复
-
----
-
-## 里程碑
-
-### Iteration 1
-
-* 基础目录结构
-* Git source
-* scan / list / lock
-* Zod schema + state migration
-
-### Iteration 2
-
-* config TUI
-* Claude / OpenCode / Codex / agents 分发
-* symlink deploy + doctor
-
-### Iteration 3
-
-* OpenClaw copy deploy
-* ClawHub adapter
-* update / uninstall / diff
-
-### Iteration 4
-
-* search
-* well-known adapter
-* Homebrew 发布
-* advanced config / custom channel path
-
----
-
-## 剩余开放问题
-
-1. `SM_HOME` 是否允许 `skillflow_HOME` override。
-2. `search` 的 GitHub 模式是否做 repo search，还是 MVP 先只接受 locator。
-3. 是否要在 `config` 里暴露“高级策略切换”，还是完全自动化。
-4. P1 是否支持 project scope。
-
----
-
-## 我的最终建议
-
-如果你要尽快开工，这一版最值得立刻落地的不是更多竞品调研，而是下面这组最小闭环：
-
-**TypeScript + Node 22 + oclif + Ink + Zod + simple-git**
-**先做 Git Source + Claude/OpenCode/Codex/agents symlink + OpenClaw copy + manifest/lock + doctor**
-
-这条路线最稳，原因是它同时满足：
-
-* 你的两层树状交互诉求
-* 多渠道差异化投影
-* 后续扩展 ClawHub / well-known source
-* 真实可维护的 CLI 工程形态
-
-下一步最合适的是把这份 PRD继续压成**工程实施文档**，具体到命令参数 spec、state JSON schema、adapter 接口、错误码与 TUI 组件树。
-
-[1]: https://code.claude.com/docs/en/skills?utm_source=chatgpt.com "Extend Claude with skills - Claude Code Docs"
-[2]: https://docs.openclaw.ai/tools/clawhub?utm_source=chatgpt.com "ClawHub - OpenClaw"
-[3]: https://nodejs.org/en/blog/announcements/node-18-eol-support?utm_source=chatgpt.com "Beware of End-of-Life Node.js Versions - Upgrade or Seek ..."
-[4]: https://agentskills.io/specification?utm_source=chatgpt.com "Specification"
-[5]: https://github.com/vercel-labs/skills?utm_source=chatgpt.com "vercel-labs/skills: The open agent skills tool - npx skills"
-[6]: https://developers.openai.com/codex/skills/?utm_source=chatgpt.com "Agent Skills – Codex"
-[7]: https://docs.openclaw.ai/tools/skills?utm_source=chatgpt.com "Skills - OpenClaw"
-[8]: https://docs.github.com/en/rest/git/trees?utm_source=chatgpt.com "REST API endpoints for Git trees"
-[9]: https://www.mintlify.com/docs/ai/skillmd?utm_source=chatgpt.com "skill.md"
-[10]: https://opencode.ai/docs/skills/?utm_source=chatgpt.com "Agent Skills"
-[11]: https://docs.openclaw.ai/gateway/configuration?utm_source=chatgpt.com "Configuration - OpenClaw"
-[12]: https://oclif.github.io/?utm_source=chatgpt.com "oclif: The Open CLI Framework"
-[13]: https://github.com/vadimdemedes/ink?utm_source=chatgpt.com "Ink - React for interactive command-line apps ..."
-[14]: https://zod.dev/?utm_source=chatgpt.com "Zod: Intro"
-[15]: https://www.npmjs.com/package/simple-git?utm_source=chatgpt.com "simple-git"
-[16]: https://www.npmjs.com/package/yaml?utm_source=chatgpt.com "yaml"
-[17]: https://vitest.dev/?utm_source=chatgpt.com "Vitest | Next Generation testing framework"
-[18]: https://docs.github.com/actions/guides/building-and-testing-nodejs?utm_source=chatgpt.com "Building and testing Node.js"