flower-trellis 0.3.1-beta.1 → 0.3.1-beta.2

package/README.md

@@ -106,7 +106,7 @@ flower banner → 平台多选菜单 → Trellis 原生交互(模板 / monorepo
 - **统一品牌头部**:Trellis 子进程在伪终端(`node-pty`)中运行,其原生的模板 / monorepo / 冲突等交互完整保留,但重复打印的启动 banner 被过滤,全程只呈现一个 flower banner。
 - **按平台铺设技能**:Claude 铺到 `.claude/skills`,Codex / Gemini 等铺到 `.agents/skills`;并对 codex 做后处理(兼容清理旧 `config.toml` 的 `[features.multi_agent_v2]`,在保留上游 hooks 的基础上补全 `SessionStart`)。
 - **幂等执行**:`workflow.md` 注入前先按 `BEGIN/END` 标记清除旧块再重注入(块数恒定,不会翻倍,首次注入前备份 `.bak`);技能文件覆盖式铺设,并通过 `.trellis/.flower-manifest.json` 记录已铺路径,升级时删除已淘汰项。
-- **上线事项账本**:强化包通过 finish-work skill override 在归档前智能识别 SQL、配置、批处理 / 部署脚本 / 数据修复、外部系统 / 依赖平台等上线事项,必要时写入任务 `release.md`;`trellis-release` 可在正式上线前汇总多个任务的 `release.md` 生成版本 / 批次操作单。
+- **上线事项账本**:强化包通过 finish-work skill override 在归档前智能识别 SQL、配置、批处理 / 部署脚本 / 数据修复、外部系统 / 依赖平台等上线事项,必要时写入任务 `release.md`;`trellis-release` 可在正式上线前核对任务文档、`release.md` 和 git 证据,生成 `YYYY-MM-DD-<release-slug>.md` 格式的版本 / 批次操作单。
 - **安全中止**:`Ctrl+C` 取消后不会继续叠加。
 
 ## 强化包与更新

package/enhancements/0.6/.agents/skills/trellis-release/SKILL.md

@@ -1,21 +1,29 @@
 ---
 name: trellis-release
-description: "汇总 Trellis 任务 release.md，生成版本或上线批次操作单。用于正式上线前整理 SQL、配置、批处理、外部系统、回滚和验证事项。"
+description: "核对并汇总 Trellis 任务 release.md，生成版本或上线批次操作单。用于正式上线前整理 SQL、配置、批处理、外部系统、回滚、验证事项和文档漂移风险。"
 ---
 
-# Release Summary
+# 上线操作单汇总
 
-汇总一组 Trellis 任务的 `release.md`，生成版本 / 上线批次操作单：`.trellis/releases/<release-name>.md`。
+核对并汇总一组 Trellis 任务的上线事项，生成版本 / 上线批次操作单：`.trellis/releases/<release-file>.md`。
 
-本 skill 只整理上线事项，不执行上线、不提交代码、不推送代码。
+本 skill 只整理和核对上线事项，不执行上线、不提交代码、不推送代码。
 
 ## 适用场景
 
 - 用户说“生成上线单”“汇总 release.md”“正式上线前整理操作单”。
 - 用户说“版本上线总结”“汇总这些任务的上线事项”“trellis-release”。
 - 用户需要把多个任务的 SQL、配置、批处理、外部系统上线、回滚和验证事项合成一份操作单。
+- 用户担心任务文档、实现代码、提交记录或上下文压缩后发生文档漂移，需要上线前复核。
 
-## Step 1: 确定 release 名称和任务集合
+## 核心原则
+
+- **先核对，再汇总**：不能只复制已有 `release.md`。必须对照任务文档、实现计划、检查记录和 git 证据判断上线事项是否完整。
+- **文件证据优先**：即使刚经历上下文压缩、会话恢复或你“记得”之前做过什么，也必须重新读取本地文件和 git 证据。
+- **不静默相信旧文档**：已有 `release.md` 只能作为输入之一。发现缺失、冲突、过期或证据不足时，在批次上线单里标记 `Needs human review`。
+- **保留来源引用**：每条上线事项都要标注任务来源，例如 `[06-17-example-task]`。
+
+## Step 1: 确定任务集合与 release 文件名
 
 先读取本地任务目录，不要凭记忆回答：
 
@@ -31,27 +39,60 @@ python3 ./.trellis/scripts/task.py list-archive || true
 - 如果用户给出版本名、日期范围、wave、批次名，从 `.trellis/tasks/` 和 `.trellis/tasks/archive/` 中匹配候选任务。
 - 如果用户只说“当前版本”但没有足够上下文，先列出候选任务并问一个问题确认范围。
 
-release 名称生成规则：
+release 文件名生成规则：
 
-- 用户给出名称时使用用户名称，并清理成安全文件名。
-- 用户未给出时使用日期，例如 `release-2026-06-17`。
-- 输出路径固定为 `.trellis/releases/<release-name>.md`。
+- 用户显式给出文件名 / release 名称时，使用用户名称，并清理成安全文件名。
+- 用户未给出时，使用 `YYYY-MM-DD-<release-slug>.md`。
+- `<release-slug>` 优先来自用户给出的版本号、批次名、wave 名称；推导不到时使用 `release`。
+- 示例：`2026-06-25-v0.3.1-beta.1.md`、`2026-06-25-h0-relay-batch.md`、`2026-06-25-release.md`。
+- 文件名清理规则：转小写，空白替换为 `-`，移除路径分隔符和除字母、数字、点、下划线、短横线以外的字符，合并连续短横线，去掉首尾短横线。
+- 输出路径固定为 `.trellis/releases/<release-file>.md`。
+- 如果目标文件已存在，追加 `-2`、`-3` 等数字后缀，不能覆盖已有上线单。
 
-## Step 2: 读取任务上线事项
+## Step 2: 读取任务材料和 git 证据
 
 对每个任务读取：
 
 - `task.json`
 - `prd.md`
+- `design.md`（如果存在）
+- `implement.md`（如果存在）
+- `implement.jsonl`
+- `check.jsonl`
 - `release.md`（如果存在）
 
-缺失 `release.md` 时：
+同时读取可用的本地证据：
+
+- `task.json` 中记录的提交、分支、相关文件和任务状态。
+- 任务文档中明确提到的代码路径、配置路径、脚本路径和外部系统。
+- 近期 work commit 的文件列表和 diff，例如 `git log --oneline --name-only -n 30`、`git show --name-only <hash>`。
+- 当前 `git status --porcelain` / `git diff --name-only` 只作为风险提示；未提交 dirty path 不能直接当作已完成上线内容。
+
+核对时重点搜索这些上线信号：
+
+- SQL、migration、DDL、DML、数据库脚本。
+- 环境变量、配置中心、feature flag、权限、密钥、外部地址。
+- 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑。
+- H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统。
+- 回滚步骤、上线顺序、上线后验证要求。
+
+## Step 3: 核对 release.md 漂移
 
-- 在汇总中列入“未记录上线事项的任务”。
-- 默认不阻塞汇总。
-- 不要自动为这些任务生成 `release.md`；单任务记录由 finish-work skill override 注入块负责。
+对每个任务形成核对结论：
 
-## Step 3: 汇总分类
+- `已覆盖`：已有 `release.md` 与任务材料、实现影响面和提交证据一致。
+- `缺失 release.md`：任务没有 `release.md`，但批次上线单仍要记录核对结果。
+- `疑似漂移`：已有 `release.md` 与任务材料 / 提交证据不一致，或明显遗漏上线信号。
+- `Needs human review`：证据不足、上下文不完整、dirty path 影响判断，或无法确认外部系统是否已处理。
+
+处理规则：
+
+- 缺失 `release.md` 时，在汇总中列入“未记录上线事项的任务”，并写明从其他证据核对出的事项或风险。
+- 不要自动为这些任务生成单任务 `release.md`；单任务记录由 finish-work skill override 注入块负责。
+- 已有 `release.md` 发生漂移时，不要静默改写原任务文件；在批次上线单的“风险标记 / 需人工复核”中记录差异。
+- 如果无法高置信判断某项是否需要上线操作，保留为 `Needs human review`，不要写成“无”。
+
+## Step 4: 汇总分类
 
 生成操作单草案，按以下固定小节归并：
 
@@ -59,8 +100,18 @@ release 名称生成规则：
 # 上线操作单：<release-name>
 
 ## 范围
-- 任务：<task>
+- 文件：.trellis/releases/<release-file>.md
 - 生成时间：<date>
+- 任务：
+  - <task>
+
+## 核对摘要
+| 任务 | release.md | 核对证据 | 结论 |
+| --- | --- | --- | --- |
+| <task> | 存在 / 缺失 | prd / implement / check / git | 已覆盖 / 缺失 release.md / 疑似漂移 / Needs human review |
+
+## 风险标记 / 需人工复核
+- 无
 
 ## SQL 变更
 - 无
@@ -93,32 +144,41 @@ release 名称生成规则：
 - 环境变量、配置中心、feature flag、权限、密钥、外部地址放入“配置变更”。
 - 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑放入“批处理 / 部署脚本 / 数据修复”。
 - H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统，放入“外部系统 / 依赖平台上线”。
+- 回滚和验证不能只写模板默认值；如果任务材料或 git 证据显示存在特殊回滚 / 验证要求，必须覆盖默认项。
 - 每条内容保留任务来源引用，例如 `[06-17-example-task]`。
 
-## Step 4: 写盘确认
+## Step 5: 写盘确认
 
-写入 `.trellis/releases/<release-name>.md` 前，展示：
+写入 `.trellis/releases/<release-file>.md` 前，展示：
 
 - 目标路径。
 - 纳入的任务列表。
+- 文件名生成依据和冲突处理结果。
+- 每个任务的核对结论。
 - 未记录上线事项的任务列表。
+- 漂移 / 风险 / 需人工复核列表。
 - 草案摘要。
 
 等待用户明确确认后再写盘。用户要求调整范围、名称或内容时，先更新草案再重新确认。
 
-## Step 5: 输出结果
+## Step 6: 输出结果
 
 写盘后报告：
 
 - 已生成的 release 文件路径。
 - 纳入任务数量。
 - 未记录上线事项任务数量。
+- `疑似漂移` / `Needs human review` 数量。
 - 上线前仍需人工复核的事项。
 
 ## 反模式
 
 - 自动执行 SQL、脚本、部署或外部系统操作。
+- 只汇总已有 `release.md`，不核对任务材料和 git 证据。
+- 上下文压缩或会话恢复后依赖记忆判断上线事项。
 - 把缺失 `release.md` 的任务静默忽略。
+- 发现旧 `release.md` 与实现证据不一致时仍写“无风险”。
 - 汇总时丢失任务来源引用。
 - 把 H0 接口中转平台等外部依赖混入普通配置变更。
-- 在用户确认前写入 `.trellis/releases/<release-name>.md`。
+- 在用户确认前写入 `.trellis/releases/<release-file>.md`。
+- 覆盖已有 `.trellis/releases/` 文件。

package/enhancements/0.6/.claude/skills/trellis-release/SKILL.md

@@ -1,21 +1,29 @@
 ---
 name: trellis-release
-description: "汇总 Trellis 任务 release.md，生成版本或上线批次操作单。用于正式上线前整理 SQL、配置、批处理、外部系统、回滚和验证事项。"
+description: "核对并汇总 Trellis 任务 release.md，生成版本或上线批次操作单。用于正式上线前整理 SQL、配置、批处理、外部系统、回滚、验证事项和文档漂移风险。"
 ---
 
-# Release Summary
+# 上线操作单汇总
 
-汇总一组 Trellis 任务的 `release.md`，生成版本 / 上线批次操作单：`.trellis/releases/<release-name>.md`。
+核对并汇总一组 Trellis 任务的上线事项，生成版本 / 上线批次操作单：`.trellis/releases/<release-file>.md`。
 
-本 skill 只整理上线事项，不执行上线、不提交代码、不推送代码。
+本 skill 只整理和核对上线事项，不执行上线、不提交代码、不推送代码。
 
 ## 适用场景
 
 - 用户说“生成上线单”“汇总 release.md”“正式上线前整理操作单”。
 - 用户说“版本上线总结”“汇总这些任务的上线事项”“trellis-release”。
 - 用户需要把多个任务的 SQL、配置、批处理、外部系统上线、回滚和验证事项合成一份操作单。
+- 用户担心任务文档、实现代码、提交记录或上下文压缩后发生文档漂移，需要上线前复核。
 
-## Step 1: 确定 release 名称和任务集合
+## 核心原则
+
+- **先核对，再汇总**：不能只复制已有 `release.md`。必须对照任务文档、实现计划、检查记录和 git 证据判断上线事项是否完整。
+- **文件证据优先**：即使刚经历上下文压缩、会话恢复或你“记得”之前做过什么，也必须重新读取本地文件和 git 证据。
+- **不静默相信旧文档**：已有 `release.md` 只能作为输入之一。发现缺失、冲突、过期或证据不足时，在批次上线单里标记 `Needs human review`。
+- **保留来源引用**：每条上线事项都要标注任务来源，例如 `[06-17-example-task]`。
+
+## Step 1: 确定任务集合与 release 文件名
 
 先读取本地任务目录，不要凭记忆回答：
 
@@ -31,27 +39,60 @@ python3 ./.trellis/scripts/task.py list-archive || true
 - 如果用户给出版本名、日期范围、wave、批次名，从 `.trellis/tasks/` 和 `.trellis/tasks/archive/` 中匹配候选任务。
 - 如果用户只说“当前版本”但没有足够上下文，先列出候选任务并问一个问题确认范围。
 
-release 名称生成规则：
+release 文件名生成规则：
 
-- 用户给出名称时使用用户名称，并清理成安全文件名。
-- 用户未给出时使用日期，例如 `release-2026-06-17`。
-- 输出路径固定为 `.trellis/releases/<release-name>.md`。
+- 用户显式给出文件名 / release 名称时，使用用户名称，并清理成安全文件名。
+- 用户未给出时，使用 `YYYY-MM-DD-<release-slug>.md`。
+- `<release-slug>` 优先来自用户给出的版本号、批次名、wave 名称；推导不到时使用 `release`。
+- 示例：`2026-06-25-v0.3.1-beta.1.md`、`2026-06-25-h0-relay-batch.md`、`2026-06-25-release.md`。
+- 文件名清理规则：转小写，空白替换为 `-`，移除路径分隔符和除字母、数字、点、下划线、短横线以外的字符，合并连续短横线，去掉首尾短横线。
+- 输出路径固定为 `.trellis/releases/<release-file>.md`。
+- 如果目标文件已存在，追加 `-2`、`-3` 等数字后缀，不能覆盖已有上线单。
 
-## Step 2: 读取任务上线事项
+## Step 2: 读取任务材料和 git 证据
 
 对每个任务读取：
 
 - `task.json`
 - `prd.md`
+- `design.md`（如果存在）
+- `implement.md`（如果存在）
+- `implement.jsonl`
+- `check.jsonl`
 - `release.md`（如果存在）
 
-缺失 `release.md` 时：
+同时读取可用的本地证据：
+
+- `task.json` 中记录的提交、分支、相关文件和任务状态。
+- 任务文档中明确提到的代码路径、配置路径、脚本路径和外部系统。
+- 近期 work commit 的文件列表和 diff，例如 `git log --oneline --name-only -n 30`、`git show --name-only <hash>`。
+- 当前 `git status --porcelain` / `git diff --name-only` 只作为风险提示；未提交 dirty path 不能直接当作已完成上线内容。
+
+核对时重点搜索这些上线信号：
+
+- SQL、migration、DDL、DML、数据库脚本。
+- 环境变量、配置中心、feature flag、权限、密钥、外部地址。
+- 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑。
+- H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统。
+- 回滚步骤、上线顺序、上线后验证要求。
+
+## Step 3: 核对 release.md 漂移
 
-- 在汇总中列入“未记录上线事项的任务”。
-- 默认不阻塞汇总。
-- 不要自动为这些任务生成 `release.md`；单任务记录由 finish-work skill override 注入块负责。
+对每个任务形成核对结论：
 
-## Step 3: 汇总分类
+- `已覆盖`：已有 `release.md` 与任务材料、实现影响面和提交证据一致。
+- `缺失 release.md`：任务没有 `release.md`，但批次上线单仍要记录核对结果。
+- `疑似漂移`：已有 `release.md` 与任务材料 / 提交证据不一致，或明显遗漏上线信号。
+- `Needs human review`：证据不足、上下文不完整、dirty path 影响判断，或无法确认外部系统是否已处理。
+
+处理规则：
+
+- 缺失 `release.md` 时，在汇总中列入“未记录上线事项的任务”，并写明从其他证据核对出的事项或风险。
+- 不要自动为这些任务生成单任务 `release.md`；单任务记录由 finish-work skill override 注入块负责。
+- 已有 `release.md` 发生漂移时，不要静默改写原任务文件；在批次上线单的“风险标记 / 需人工复核”中记录差异。
+- 如果无法高置信判断某项是否需要上线操作，保留为 `Needs human review`，不要写成“无”。
+
+## Step 4: 汇总分类
 
 生成操作单草案，按以下固定小节归并：
 
@@ -59,8 +100,18 @@ release 名称生成规则：
 # 上线操作单：<release-name>
 
 ## 范围
-- 任务：<task>
+- 文件：.trellis/releases/<release-file>.md
 - 生成时间：<date>
+- 任务：
+  - <task>
+
+## 核对摘要
+| 任务 | release.md | 核对证据 | 结论 |
+| --- | --- | --- | --- |
+| <task> | 存在 / 缺失 | prd / implement / check / git | 已覆盖 / 缺失 release.md / 疑似漂移 / Needs human review |
+
+## 风险标记 / 需人工复核
+- 无
 
 ## SQL 变更
 - 无
@@ -93,32 +144,41 @@ release 名称生成规则：
 - 环境变量、配置中心、feature flag、权限、密钥、外部地址放入“配置变更”。
 - 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑放入“批处理 / 部署脚本 / 数据修复”。
 - H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统，放入“外部系统 / 依赖平台上线”。
+- 回滚和验证不能只写模板默认值；如果任务材料或 git 证据显示存在特殊回滚 / 验证要求，必须覆盖默认项。
 - 每条内容保留任务来源引用，例如 `[06-17-example-task]`。
 
-## Step 4: 写盘确认
+## Step 5: 写盘确认
 
-写入 `.trellis/releases/<release-name>.md` 前，展示：
+写入 `.trellis/releases/<release-file>.md` 前，展示：
 
 - 目标路径。
 - 纳入的任务列表。
+- 文件名生成依据和冲突处理结果。
+- 每个任务的核对结论。
 - 未记录上线事项的任务列表。
+- 漂移 / 风险 / 需人工复核列表。
 - 草案摘要。
 
 等待用户明确确认后再写盘。用户要求调整范围、名称或内容时，先更新草案再重新确认。
 
-## Step 5: 输出结果
+## Step 6: 输出结果
 
 写盘后报告：
 
 - 已生成的 release 文件路径。
 - 纳入任务数量。
 - 未记录上线事项任务数量。
+- `疑似漂移` / `Needs human review` 数量。
 - 上线前仍需人工复核的事项。
 
 ## 反模式
 
 - 自动执行 SQL、脚本、部署或外部系统操作。
+- 只汇总已有 `release.md`，不核对任务材料和 git 证据。
+- 上下文压缩或会话恢复后依赖记忆判断上线事项。
 - 把缺失 `release.md` 的任务静默忽略。
+- 发现旧 `release.md` 与实现证据不一致时仍写“无风险”。
 - 汇总时丢失任务来源引用。
 - 把 H0 接口中转平台等外部依赖混入普通配置变更。
-- 在用户确认前写入 `.trellis/releases/<release-name>.md`。
+- 在用户确认前写入 `.trellis/releases/<release-file>.md`。
+- 覆盖已有 `.trellis/releases/` 文件。

package/enhancements/0.6/overrides/skills/trellis-finish-work.md

@@ -10,23 +10,37 @@ Run this step after finish-work Step 2 dirty-path classification succeeds and be
 
 This step is non-blocking. Do not add an extra user confirmation question, and do not block finish-work solely because `release.md` is absent.
 
-For the active task, read the available task files: `task.json`, `prd.md`, `design.md`, `implement.md`, `implement.jsonl`, `check.jsonl`, and any existing `release.md`. Also use the recent work commits, `git diff --name-only`, and the dirty-path classification already gathered during finish-work preflight.
+This step must be evidence-based. If the conversation was compacted, resumed, or interrupted, do not rely on memory from the earlier context. Re-read the task files and git evidence before deciding whether release operations exist.
 
-If `<task>/release.md` already exists, preserve it and only update it when the current task context shows an obvious missing release operation. If no `release.md` exists:
+For the active task, read the available task files: `task.json`, `prd.md`, `design.md`, `implement.md`, `implement.jsonl`, `check.jsonl`, and any existing `release.md`. Also use recent work commits, `git log --oneline --name-only`, `git show --name-only <hash>` when a work commit is known, `git diff --name-only`, and the dirty-path classification already gathered during finish-work preflight.
+
+If `<task>/release.md` already exists, compare it with the task requirements, implementation plan, check context, changed files, and commit evidence. Preserve it when it is still accurate. Update it only when the current task context shows an obvious missing release operation or obvious document drift. If drift is plausible but not certain, keep the risk visible and mark the conclusion as `Needs human review`.
+
+If no `release.md` exists:
 
 - High-confidence release work exists: write `<task>/release.md`.
-- High-confidence no release work exists: do not create `release.md`; mention in the final finish-work report that no release operations were identified.
+- High-confidence no release work exists after re-reading task files and git evidence: do not create `release.md`; mention in the final finish-work report that no release operations were identified.
 - Signals are uncertain but release risk exists: write `<task>/release.md` and mark the conclusion as `Needs human review`.
 
 Release-operation signals include SQL or migrations; configuration, environment variables, feature flags, permissions, secrets, or external endpoints; deployment scripts, one-off commands, data repair, scheduled task triggers, background job reruns, or other batch operations; and external systems or dependent platforms that must be released or coordinated, such as H0 API relay / gateway platforms, messaging platforms, or third-party admin consoles.
 
-When writing `release.md`, use this structure:
+When writing or updating `release.md`, use this structure:
 
 ```markdown
 # Release Operations
 
 ## Conclusion
-Release operations exist. / Needs human review.
+Release operations exist. / No release operations identified. / Needs human review.
+
+## Evidence Checked
+- task.json
+- prd.md
+- design.md / implement.md / implement.jsonl / check.jsonl
+- release.md
+- git commits / changed files
+
+## Drift Check
+Existing release.md is accurate. / Missing release.md. / Drift suspected. / Needs human review.
 
 ## SQL Changes
 None
@@ -52,6 +66,8 @@ Verify according to task acceptance criteria.
 
 Classify deployment scripts, one-off commands, data repairs, scheduled task triggers, and job reruns under `Batch / Deployment Scripts / Data Repair`. Classify systems outside the current repository that need coordinated release, such as H0 API relay platforms, under `External Systems / Dependent Platforms`.
 
+Do not write `None`, `No release operations identified`, or `Rollback code only` out of habit. Use those defaults only after checking the task files and git evidence. If the task changed deployment scripts, configuration, SQL, external platforms, permissions, scheduled jobs, or data, record the concrete item and source.
+
 If multiple tasks will be archived in the same finish-work run, process the active task at minimum. Process extra archived tasks only when Step 1 provides enough local context to infer safely; do not add per-task confirmation prompts.
 
 <!-- END skill-garden skill override trellis-finish-work v0.6 -->

package/enhancements/MANIFEST.json

@@ -1,7 +1,7 @@
 {
-  "syncedAt": "2026-06-25T06:19:19.136Z",
+  "syncedAt": "2026-06-25T10:31:30.060Z",
   "syncedFrom": "vendor/skill-garden/.trellis",
-  "sourceCommit": "26a0f2f310760e776130219a8287f8205dc20614",
+  "sourceCommit": "884cfbda179eec60c3481356c0abe0c9dc9e4f15",
   "variants": {
     "old": {
       "claudeSkills": [],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flower-trellis",
-  "version": "0.3.1-beta.1",
+  "version": "0.3.1-beta.2",
   "description": "一键安装/升级 Trellis 并自动融合 skill-garden 强化包(默认 Claude + agents)",
   "type": "module",
   "bin": {