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

package/README.md

@@ -6,7 +6,7 @@
 
 > 一条命令装好 [Trellis](https://docs.trytrellis.app/) 工程框架,并自动融合 **skill-garden** 强化包。
 
-`flower-trellis` 是 Trellis 的 npm 封装 CLI,把原本要分两步的工作合并为一键完成:安装/升级 Trellis 本体,并在其上叠加 skill-garden 的强化包(一组 `trellis-*` 技能与 workflow override)。强化包以快照形式随包发布,安装过程**零网络依赖**。
+`flower-trellis` 是 Trellis 的 npm 封装 CLI,把原本要分两步的工作合并为一键完成:安装/升级 Trellis 本体,并在其上叠加 skill-garden 的强化包(一组 `trellis-*` 技能与 workflow / skill override)。强化包以快照形式随包发布,安装过程**零网络依赖**。
 
 底层调用官方 `@mindfoldhq/trellis` 的 `init` / `update`,并按目标项目的 Trellis 版本自动选择匹配的强化包变体(`old` / `0.5` / `0.6`)。
 
@@ -29,6 +29,14 @@ npm i -g flower-trellis@beta
 
 **环境要求**:Node.js ≥ 18.17.0。
 
+全局安装 / 升级 `flower-trellis` 时会同步全局 `@mindfoldhq/trellis` 到当前捆绑版本,因此直接运行 `trellis ...` 也会与 `flower-trellis -v` 中的 `trellis (bundled)` 保持一致。若全局 npm 目录权限不足导致同步失败,安装会中止并提示手动执行的命令,例如:
+
+```bash
+npm install -g @mindfoldhq/trellis@<版本号>
+```
+
+`npx flower-trellis ...` 属于临时免安装运行,不会改写本机全局 `trellis`。
+
 ## 用法
 
 ```bash
@@ -98,6 +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` 生成版本 / 批次操作单。
 - **安全中止**:`Ctrl+C` 取消后不会继续叠加。
 
 ## 强化包与更新

package/enhancements/0.6/.agents/skills/trellis-extract-prd/SKILL.md

@@ -33,6 +33,7 @@ description: "Extract a cohesive task PRD faithfully from a source requirements
 - **版本规划产物路径**（默认尝试 `doc/<版本>/任务拆分与waves.md`）
 - **Task ID / task 候选名称**
 - **Wave ID / wave 名称**
+- **批量生成范围**（例如某个版本规划中的全部 task，或指定 wave 下的 task）
 
 ---
 
@@ -61,6 +62,13 @@ description: "Extract a cohesive task PRD faithfully from a source requirements
 - 散射组归属
 - 依赖 task
 - 可验收结果 / 可提测性
+- Task 创建顺序和 slug 建议（如存在）
+
+如果用户要求批量生成多个 task：
+- 必须优先按版本规划产物中的「Task 创建顺序」执行。
+- 如果版本规划产物没有「Task 创建顺序」，必须先补齐或请用户确认顺序；不要按需求文档顺序、Task ID 字面顺序或临时判断直接创建。
+- 同一 wave 的 task 必须连续创建，不能被其他 wave 插开。
+- 跨 wave 支撑 task 按版本规划标注放在服务的首个 wave 之前，或作为跨 wave 前置项单独说明。
 
 如果版本规划产物存在但找不到用户指定的 task 候选：
 - 不要猜测映射
@@ -167,6 +175,27 @@ python3 .trellis/scripts/task.py create "<PRD标题>" \
   --description "<TL;DR「做什么」一句话>"
 ```
 
+如果基于版本规划批量创建 task，按以下规则生成 slug：
+
+```text
+<version>-wNN-tNN-<task-slug>
+```
+
+- `wNN`：wave 顺序号，例如 `w01`、`w02`
+- `tNN`：全版本 task 创建顺序号，例如 `t01`、`t02`
+- `<task-slug>`：保留业务语义的短 slug
+
+示例：
+
+```bash
+python3 .trellis/scripts/task.py create "项目列表反馈投标状态" \
+  --slug "srm-iqs-v141-w01-t01-project-list-feedback-bid-status" \
+  --priority P2 \
+  --description "项目列表反馈投标状态"
+```
+
+不要把日期写入 `--slug`；`task.py create` 会自动添加 `MM-DD-` 前缀。批量创建时，必须按版本规划的「Task 创建顺序」逐个执行上述命令。
+
 创建完成后，根据 PRD 中的分析补充 `task.json` 中的字段：
 - `dev_type`：`frontend` / `backend` / `fullstack`
 - `relatedFiles`：PRD Technical Notes 中识别的关键文件路径
@@ -210,6 +239,7 @@ python3 .trellis/scripts/task.py create "<PRD标题>" \
 | **散射完整** | 至少对 2-3 个关键实体做过全文搜索 |
 | **任务边界匹配** | 如存在版本规划产物，Scope 是否严格落在 task 候选范围内 |
 | **Wave 匹配** | PRD / `task.json.meta` 的 wave 是否与版本规划一致 |
+| **创建顺序匹配** | 批量生成时，实际创建顺序和 slug 是否遵循版本规划的「Task 创建顺序」 |
 
 ---
 
@@ -227,6 +257,8 @@ python3 .trellis/scripts/task.py create "<PRD标题>" \
 - ❌ 把一个内聚 task 拆成页面 / 接口 / 字段碎片
 - ❌ 未找到版本规划产物时自行编造 wave id 或 Task ID
 - ❌ 把 wave 当成独立 task 目录或 `task.py` 状态
+- ❌ 批量创建 task 时忽略版本规划的「Task 创建顺序」
+- ❌ slug 缺少 `wNN-tNN` 等稳定排序键，导致同一 wave 的 task 在目录中分散
 
 ---
 

package/enhancements/0.6/.agents/skills/trellis-plan-version/SKILL.md

@@ -169,7 +169,25 @@ description: "Generate a version development plan from a source requirements doc
 
 > 如果一批只包含基础设施、迁移、公共组件或接口契约，不能直接标成“可独立提测 wave”。应作为后续 wave 的前置依赖，或并入首个能形成业务验收闭环的 wave。
 
-#### 4.2 输出 task / wave 拆分结果
+#### 4.2 Task 创建顺序
+
+在输出 task / wave 拆分结果时，必须同时给出明确的 task 创建顺序。创建顺序用于后续 `trellis-extract-prd` 批量生成具体 task，不能只依赖 Task ID、需求文档顺序或人工临时创建顺序。
+
+排序规则：
+- 先按 wave 分组，同一 wave 的 task 必须连续出现。
+- 同一 wave 内按依赖关系排序，前置能力在前。
+- 无依赖关系时，按可提测闭环优先级、风险或用户确认的优先级排序。
+- 跨 wave 支撑 task 放在它服务的首个 wave 之前，或明确标记为跨 wave 前置项。
+
+slug 建议使用：
+
+```text
+<version>-wNN-tNN-<task-slug>
+```
+
+其中 `wNN` 表示 wave 顺序，`tNN` 表示全版本 task 创建顺序。后续执行 `task.py create --slug` 时，`--slug` 只传上述排序 slug，不要加入日期前缀；`task.py create` 会自动添加 `MM-DD-` 前缀。
+
+#### 4.3 输出 task / wave 拆分结果
 
 ```markdown
 ## <版本> 任务拆分与 Waves
@@ -182,6 +200,11 @@ description: "Generate a version development plan from a source requirements doc
 | Task ID | Task 名称 | 本 task 范围 | 不在范围 | 来源需求 | 散射组 | 依赖 | 主要 Wave | 可验收结果 | 风险 |
 |---------|-----------|-------------|----------|----------|--------|------|-----------|------------|------|
 
+### Task 创建顺序
+
+| 创建序号 | Wave | Wave 内序号 | Task ID | Task 名称 | Slug 建议 | 排序原因 |
+|----------|------|-------------|---------|-----------|-----------|----------|
+
 ### Wave 计划
 
 | Wave | 目标 | 包含 task | 提测范围 | 前置条件 | 完成条件 | 可独立提测 |
@@ -243,6 +266,7 @@ doc/
 
 `任务拆分与waves.md` 是后续单 task PRD 的版本级来源：
 - `trellis-extract-prd` 从其中读取 task 候选、wave、来源需求位置和边界
+- `trellis-extract-prd` 批量创建 task 时必须按其中的“Task 创建顺序”执行
 - `trellis-verify-task` 用它检查“版本需求 -> task -> wave”的覆盖和边界一致性
 
 ---
@@ -257,6 +281,8 @@ doc/
 - ❌ 散射型变更分给不同 task 且没有统一归组理由
 - ❌ wave 只按日期、人员或模块排序，没有可提测目标和完成条件
 - ❌ 把只有基础设施 / 迁移 / 公共组件的半成品批次标成可提测 wave
+- ❌ 生成 task 创建顺序时让同一 wave 的 task 被其他 wave 插开
+- ❌ slug 建议缺少稳定排序键，导致目录自然排序无法按 wave 聚合
 - ❌ 生成 task / wave 拆分后不等待用户确认，直接做工时评估或创建 task
 - ❌ 假设文档有特定格式或特定的角色分工模式
 - ❌ 当多个来源的优先级冲突时不明确说明以哪个为准

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

@@ -0,0 +1,124 @@
+---
+name: trellis-release
+description: "汇总 Trellis 任务 release.md，生成版本或上线批次操作单。用于正式上线前整理 SQL、配置、批处理、外部系统、回滚和验证事项。"
+---
+
+# Release Summary
+
+汇总一组 Trellis 任务的 `release.md`，生成版本 / 上线批次操作单：`.trellis/releases/<release-name>.md`。
+
+本 skill 只整理上线事项，不执行上线、不提交代码、不推送代码。
+
+## 适用场景
+
+- 用户说“生成上线单”“汇总 release.md”“正式上线前整理操作单”。
+- 用户说“版本上线总结”“汇总这些任务的上线事项”“trellis-release”。
+- 用户需要把多个任务的 SQL、配置、批处理、外部系统上线、回滚和验证事项合成一份操作单。
+
+## Step 1: 确定 release 名称和任务集合
+
+先读取本地任务目录，不要凭记忆回答：
+
+```bash
+python3 ./.trellis/scripts/task.py current --source || true
+python3 ./.trellis/scripts/task.py list --mine || true
+python3 ./.trellis/scripts/task.py list-archive || true
+```
+
+根据用户输入确定任务集合：
+
+- 如果用户明确给出任务目录 / slug，优先使用这些任务。
+- 如果用户给出版本名、日期范围、wave、批次名，从 `.trellis/tasks/` 和 `.trellis/tasks/archive/` 中匹配候选任务。
+- 如果用户只说“当前版本”但没有足够上下文，先列出候选任务并问一个问题确认范围。
+
+release 名称生成规则：
+
+- 用户给出名称时使用用户名称，并清理成安全文件名。
+- 用户未给出时使用日期，例如 `release-2026-06-17`。
+- 输出路径固定为 `.trellis/releases/<release-name>.md`。
+
+## Step 2: 读取任务上线事项
+
+对每个任务读取：
+
+- `task.json`
+- `prd.md`
+- `release.md`（如果存在）
+
+缺失 `release.md` 时：
+
+- 在汇总中列入“未记录上线事项的任务”。
+- 默认不阻塞汇总。
+- 不要自动为这些任务生成 `release.md`；单任务记录由 finish-work skill override 注入块负责。
+
+## Step 3: 汇总分类
+
+生成操作单草案，按以下固定小节归并：
+
+```md
+# 上线操作单：<release-name>
+
+## 范围
+- 任务：<task>
+- 生成时间：<date>
+
+## SQL 变更
+- 无
+
+## 配置变更
+- 无
+
+## 批处理 / 部署脚本 / 数据修复
+- 无
+
+## 外部系统 / 依赖平台上线
+- 无
+
+## 上线顺序
+- 无特殊顺序
+
+## 回滚说明
+- 回滚代码即可
+
+## 上线后验证
+- 按任务验收标准验证
+
+## 未记录上线事项的任务
+- 无
+```
+
+分类规则：
+
+- SQL、migration、DDL、DML、数据库脚本放入“SQL 变更”。
+- 环境变量、配置中心、feature flag、权限、密钥、外部地址放入“配置变更”。
+- 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑放入“批处理 / 部署脚本 / 数据修复”。
+- H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统，放入“外部系统 / 依赖平台上线”。
+- 每条内容保留任务来源引用，例如 `[06-17-example-task]`。
+
+## Step 4: 写盘确认
+
+写入 `.trellis/releases/<release-name>.md` 前，展示：
+
+- 目标路径。
+- 纳入的任务列表。
+- 未记录上线事项的任务列表。
+- 草案摘要。
+
+等待用户明确确认后再写盘。用户要求调整范围、名称或内容时，先更新草案再重新确认。
+
+## Step 5: 输出结果
+
+写盘后报告：
+
+- 已生成的 release 文件路径。
+- 纳入任务数量。
+- 未记录上线事项任务数量。
+- 上线前仍需人工复核的事项。
+
+## 反模式
+
+- 自动执行 SQL、脚本、部署或外部系统操作。
+- 把缺失 `release.md` 的任务静默忽略。
+- 汇总时丢失任务来源引用。
+- 把 H0 接口中转平台等外部依赖混入普通配置变更。
+- 在用户确认前写入 `.trellis/releases/<release-name>.md`。

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

@@ -4,13 +4,14 @@ description: |
   Route trellis-implement / trellis-check execution mode with a gitignored personal preference file.
   Implement can route inline or subagent. Check defaults to check-all inline/subagent; lightweight
   trellis-check is hidden and only available when the user explicitly requests "light check" / "轻量检查".
-  Invoked from Phase 2.1 / 2.2 / 3.1 of the routing-aware workflow. Skip in non-trellis projects
+  Invoked from Phase 2.1 target=implement and Phase 2.2 target=check/check-all of the routing-aware workflow.
+  Phase 3.1 is final verification and does not normally route check again. Skip in non-trellis projects
   (no .trellis/). Not for other subagents (trellis-research / trellis-debug).
 ---
 
 # Trellis 路由器：implement / check 执行模式选择
 
-主 agent 进入 Phase 2.1 / 2.2 / 3.1 时调用本 skill，决定 implement / check 的执行模式。核心目标是减少重复打断：正常路由优先读取个人本地配置；用户要求临时改、重新选择或清除默认时，必须绕过配置并重新展示选项。
+主 agent 进入 Phase 2.1 的实现路由或 Phase 2.2 的检查路由时调用本 skill，决定 implement / check 的执行模式。Phase 3.1 属于最终确认节点，通常只确认 Phase 2.2 已通过，不作为普通 check route 入口。核心目标是减少重复打断：正常路由优先读取个人本地配置；用户要求临时改、重新选择或清除默认时，必须绕过配置并重新展示选项。
 
 个人配置只写入 `.trellis/.route-prefs.tmp`。该文件匹配 `.trellis/.gitignore` 的 `*.tmp` 规则，属于开发者本地偏好，不纳入 git，也不影响其他开发者。
 
@@ -18,7 +19,7 @@ description: |
 
 ## Step 0: 识别目标与用户意图
 
-个人 route 配置只决定“已获准执行后的模式”，不是开工授权。读取 `.trellis/.route-prefs.tmp` 前，必须确认当前 workflow 已允许进入对应 target：implement 需要任务已完成规划确认并处于 `in_progress`；check 需要已有本轮实现变更或用户明确要求检查。如果仍在 planning、等待用户确认，或用户表达“等一下 / 我再想想”，停止，不读取个人配置。
+个人 route 配置只决定“已获准执行后的模式”，不是开工授权。读取 `.trellis/.route-prefs.tmp` 前，必须确认当前 workflow 已允许进入对应 target：implement 需要任务已完成规划确认并处于 `in_progress`；check 用于 Phase 2.2 检查执行，或用户明确要求最终复查 / 轻量检查。Phase 3.1 只有在 Phase 2.2 结果缺失、check 后代码变更、风险较高或用户明确要求复查时才重新进入 check 路由。如果仍在 planning、等待用户确认，或用户表达“等一下 / 我再想想”，停止，不读取个人配置。
 
 Codex inline mode 只表示主会话默认直接执行，不是 route 选项过滤器。即使当前上下文出现 `<codex-mode>inline...do not dispatch...</codex-mode>` 或 `workflow-state:in_progress-inline`，也不能推断“只能 inline”或跳过 subagent 选项；仍必须读取 `.trellis/.route-prefs.tmp`，或在无有效配置时展示正常 inline/subagent 选项。若本 skill 的紧邻路由决定是 subagent，本步骤允许主 agent dispatch 对应 implement/check sub-agent；禁止的是绕过 `trellis-route` 直接 dispatch。
 

package/enhancements/0.6/.agents/skills/trellis-verify-task/SKILL.md

@@ -92,6 +92,7 @@ python3 ./.trellis/scripts/task.py list
 
 如果版本规划产物存在，读取其中：
 - task 候选列表
+- task 创建顺序（如存在）
 - 每个 task 的范围、非范围、来源需求、散射组、依赖、可验收结果
 - wave 计划
 - 覆盖度矩阵
@@ -215,7 +216,26 @@ Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里
 | **完成条件明确** | 有可判断的验收 / 完成标准 |
 | **不是半成品批次** | 只有基础设施、迁移、公共组件或接口契约的批次不得标为可独立提测 |
 
-#### 3.6.4 单 task PRD 与版本规划边界一致
+#### 3.6.4 task 创建顺序 / 目录排序
+
+检查版本规划产物是否包含「Task 创建顺序」。如果缺失，标记为 ⚠️ 待补充；旧版本规划可继续校验其他内容，但必须建议补齐该章节。
+
+当「Task 创建顺序」存在时，逐项检查：
+
+| 检查项 | 说明 |
+|--------|------|
+| **wave 连续** | 同一 wave 的 task 在创建顺序中连续出现，没有被其他 wave 插开 |
+| **依赖在前** | 同一 wave 内依赖 task 排在被依赖 task 之前 |
+| **跨 wave 支撑项清晰** | 跨 wave 支撑 task 放在服务的首个 wave 前，或明确标记为跨 wave 前置项 |
+| **slug 有排序键** | slug 建议包含稳定排序键，例如 `<version>-wNN-tNN-<task-slug>` |
+| **不含日期前缀** | slug 建议不包含 `MM-DD-` 日期前缀，因为 `task.py create` 会自动添加 |
+
+如当前项目已经创建了对应版本的 task 目录，且 `task.json.meta.version_plan` / `task.json.meta.wave` 足以识别同一版本 task，则额外检查实际目录自然排序：
+- 同一 wave 的 task 目录是否连续。
+- 目录名是否包含与版本规划一致的 `wNN-tNN` 排序键。
+- 如果缺少 `meta.wave`，不要编造归属；只报告“实际目录排序校验证据不足”。
+
+#### 3.6.5 单 task PRD 与版本规划边界一致
 
 如果当前校验的是单个 task：
 
@@ -226,6 +246,7 @@ Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里
 | **Scope 不碎化** | PRD 没有只截取版本规划 task 候选中的页面 / 接口 / 字段碎片，除非版本规划明确允许 |
 | **非范围一致** | PRD 的 ❌ 不在范围覆盖版本规划中明确排除的内容 |
 | **来源需求一致** | `source_requirements` 与版本规划覆盖矩阵一致 |
+| **排序归属一致** | 当前 task 的 slug / `meta.wave` 与版本规划的「Task 创建顺序」一致 |
 
 > Step 3.6 的输出必须进入统一报告。不要因为单 task PRD 通过了原始需求校验，就跳过版本级 task / wave 边界校验。
 
@@ -373,7 +394,13 @@ Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里
 | Wave | 提测目标 | 前置条件 | 完成条件 | 状态 |
 |------|----------|----------|----------|------|
 
-#### 2.5.4 当前 PRD 与版本规划边界
+#### 2.5.4 task 创建顺序 / 目录排序
+- ✅ wave 连续: X ｜ 🔴 wave 被插开: X ｜ ⚠️ 缺创建顺序 / slug 排序键: X
+
+| 创建序号 | Wave | Task | Slug / 目录 | 状态 | 问题 |
+|----------|------|------|-------------|------|------|
+
+#### 2.5.5 当前 PRD 与版本规划边界
 | 检查项 | PRD / task.json | 版本规划 | 状态 |
 |--------|-----------------|----------|------|
 
@@ -456,6 +483,7 @@ Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里
 - <过大 task> — 建议按 <业务闭环 / 复用链 / wave 提测边界> 拆成多个内聚 task
 - <版本规划中未归 wave 的 task> — 建议补 wave 归属或标记为某 wave 前置依赖
 - <不可独立提测的 wave> — 建议拆分 / 合并 wave 或补前置条件
+- <创建顺序缺失或同 wave 被插开> — 建议补「Task 创建顺序」并采用 `<version>-wNN-tNN-<task-slug>` slug
 
 ---
 

package/enhancements/0.6/.claude/skills/trellis-extract-prd/SKILL.md

@@ -33,6 +33,7 @@ description: "Extract a cohesive task PRD faithfully from a source requirements
 - **版本规划产物路径**（默认尝试 `doc/<版本>/任务拆分与waves.md`）
 - **Task ID / task 候选名称**
 - **Wave ID / wave 名称**
+- **批量生成范围**（例如某个版本规划中的全部 task，或指定 wave 下的 task）
 
 ---
 
@@ -61,6 +62,13 @@ description: "Extract a cohesive task PRD faithfully from a source requirements
 - 散射组归属
 - 依赖 task
 - 可验收结果 / 可提测性
+- Task 创建顺序和 slug 建议（如存在）
+
+如果用户要求批量生成多个 task：
+- 必须优先按版本规划产物中的「Task 创建顺序」执行。
+- 如果版本规划产物没有「Task 创建顺序」，必须先补齐或请用户确认顺序；不要按需求文档顺序、Task ID 字面顺序或临时判断直接创建。
+- 同一 wave 的 task 必须连续创建，不能被其他 wave 插开。
+- 跨 wave 支撑 task 按版本规划标注放在服务的首个 wave 之前，或作为跨 wave 前置项单独说明。
 
 如果版本规划产物存在但找不到用户指定的 task 候选：
 - 不要猜测映射
@@ -167,6 +175,27 @@ python3 .trellis/scripts/task.py create "<PRD标题>" \
   --description "<TL;DR「做什么」一句话>"
 ```
 
+如果基于版本规划批量创建 task，按以下规则生成 slug：
+
+```text
+<version>-wNN-tNN-<task-slug>
+```
+
+- `wNN`：wave 顺序号，例如 `w01`、`w02`
+- `tNN`：全版本 task 创建顺序号，例如 `t01`、`t02`
+- `<task-slug>`：保留业务语义的短 slug
+
+示例：
+
+```bash
+python3 .trellis/scripts/task.py create "项目列表反馈投标状态" \
+  --slug "srm-iqs-v141-w01-t01-project-list-feedback-bid-status" \
+  --priority P2 \
+  --description "项目列表反馈投标状态"
+```
+
+不要把日期写入 `--slug`；`task.py create` 会自动添加 `MM-DD-` 前缀。批量创建时，必须按版本规划的「Task 创建顺序」逐个执行上述命令。
+
 创建完成后，根据 PRD 中的分析补充 `task.json` 中的字段：
 - `dev_type`：`frontend` / `backend` / `fullstack`
 - `relatedFiles`：PRD Technical Notes 中识别的关键文件路径
@@ -210,6 +239,7 @@ python3 .trellis/scripts/task.py create "<PRD标题>" \
 | **散射完整** | 至少对 2-3 个关键实体做过全文搜索 |
 | **任务边界匹配** | 如存在版本规划产物，Scope 是否严格落在 task 候选范围内 |
 | **Wave 匹配** | PRD / `task.json.meta` 的 wave 是否与版本规划一致 |
+| **创建顺序匹配** | 批量生成时，实际创建顺序和 slug 是否遵循版本规划的「Task 创建顺序」 |
 
 ---
 
@@ -227,6 +257,8 @@ python3 .trellis/scripts/task.py create "<PRD标题>" \
 - ❌ 把一个内聚 task 拆成页面 / 接口 / 字段碎片
 - ❌ 未找到版本规划产物时自行编造 wave id 或 Task ID
 - ❌ 把 wave 当成独立 task 目录或 `task.py` 状态
+- ❌ 批量创建 task 时忽略版本规划的「Task 创建顺序」
+- ❌ slug 缺少 `wNN-tNN` 等稳定排序键，导致同一 wave 的 task 在目录中分散
 
 ---
 

package/enhancements/0.6/.claude/skills/trellis-plan-version/SKILL.md

@@ -169,7 +169,25 @@ description: "Generate a version development plan from a source requirements doc
 
 > 如果一批只包含基础设施、迁移、公共组件或接口契约，不能直接标成“可独立提测 wave”。应作为后续 wave 的前置依赖，或并入首个能形成业务验收闭环的 wave。
 
-#### 4.2 输出 task / wave 拆分结果
+#### 4.2 Task 创建顺序
+
+在输出 task / wave 拆分结果时，必须同时给出明确的 task 创建顺序。创建顺序用于后续 `trellis-extract-prd` 批量生成具体 task，不能只依赖 Task ID、需求文档顺序或人工临时创建顺序。
+
+排序规则：
+- 先按 wave 分组，同一 wave 的 task 必须连续出现。
+- 同一 wave 内按依赖关系排序，前置能力在前。
+- 无依赖关系时，按可提测闭环优先级、风险或用户确认的优先级排序。
+- 跨 wave 支撑 task 放在它服务的首个 wave 之前，或明确标记为跨 wave 前置项。
+
+slug 建议使用：
+
+```text
+<version>-wNN-tNN-<task-slug>
+```
+
+其中 `wNN` 表示 wave 顺序，`tNN` 表示全版本 task 创建顺序。后续执行 `task.py create --slug` 时，`--slug` 只传上述排序 slug，不要加入日期前缀；`task.py create` 会自动添加 `MM-DD-` 前缀。
+
+#### 4.3 输出 task / wave 拆分结果
 
 ```markdown
 ## <版本> 任务拆分与 Waves
@@ -182,6 +200,11 @@ description: "Generate a version development plan from a source requirements doc
 | Task ID | Task 名称 | 本 task 范围 | 不在范围 | 来源需求 | 散射组 | 依赖 | 主要 Wave | 可验收结果 | 风险 |
 |---------|-----------|-------------|----------|----------|--------|------|-----------|------------|------|
 
+### Task 创建顺序
+
+| 创建序号 | Wave | Wave 内序号 | Task ID | Task 名称 | Slug 建议 | 排序原因 |
+|----------|------|-------------|---------|-----------|-----------|----------|
+
 ### Wave 计划
 
 | Wave | 目标 | 包含 task | 提测范围 | 前置条件 | 完成条件 | 可独立提测 |
@@ -243,6 +266,7 @@ doc/
 
 `任务拆分与waves.md` 是后续单 task PRD 的版本级来源：
 - `trellis-extract-prd` 从其中读取 task 候选、wave、来源需求位置和边界
+- `trellis-extract-prd` 批量创建 task 时必须按其中的“Task 创建顺序”执行
 - `trellis-verify-task` 用它检查“版本需求 -> task -> wave”的覆盖和边界一致性
 
 ---
@@ -257,6 +281,8 @@ doc/
 - ❌ 散射型变更分给不同 task 且没有统一归组理由
 - ❌ wave 只按日期、人员或模块排序，没有可提测目标和完成条件
 - ❌ 把只有基础设施 / 迁移 / 公共组件的半成品批次标成可提测 wave
+- ❌ 生成 task 创建顺序时让同一 wave 的 task 被其他 wave 插开
+- ❌ slug 建议缺少稳定排序键，导致目录自然排序无法按 wave 聚合
 - ❌ 生成 task / wave 拆分后不等待用户确认，直接做工时评估或创建 task
 - ❌ 假设文档有特定格式或特定的角色分工模式
 - ❌ 当多个来源的优先级冲突时不明确说明以哪个为准

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

@@ -0,0 +1,124 @@
+---
+name: trellis-release
+description: "汇总 Trellis 任务 release.md，生成版本或上线批次操作单。用于正式上线前整理 SQL、配置、批处理、外部系统、回滚和验证事项。"
+---
+
+# Release Summary
+
+汇总一组 Trellis 任务的 `release.md`，生成版本 / 上线批次操作单：`.trellis/releases/<release-name>.md`。
+
+本 skill 只整理上线事项，不执行上线、不提交代码、不推送代码。
+
+## 适用场景
+
+- 用户说“生成上线单”“汇总 release.md”“正式上线前整理操作单”。
+- 用户说“版本上线总结”“汇总这些任务的上线事项”“trellis-release”。
+- 用户需要把多个任务的 SQL、配置、批处理、外部系统上线、回滚和验证事项合成一份操作单。
+
+## Step 1: 确定 release 名称和任务集合
+
+先读取本地任务目录，不要凭记忆回答：
+
+```bash
+python3 ./.trellis/scripts/task.py current --source || true
+python3 ./.trellis/scripts/task.py list --mine || true
+python3 ./.trellis/scripts/task.py list-archive || true
+```
+
+根据用户输入确定任务集合：
+
+- 如果用户明确给出任务目录 / slug，优先使用这些任务。
+- 如果用户给出版本名、日期范围、wave、批次名，从 `.trellis/tasks/` 和 `.trellis/tasks/archive/` 中匹配候选任务。
+- 如果用户只说“当前版本”但没有足够上下文，先列出候选任务并问一个问题确认范围。
+
+release 名称生成规则：
+
+- 用户给出名称时使用用户名称，并清理成安全文件名。
+- 用户未给出时使用日期，例如 `release-2026-06-17`。
+- 输出路径固定为 `.trellis/releases/<release-name>.md`。
+
+## Step 2: 读取任务上线事项
+
+对每个任务读取：
+
+- `task.json`
+- `prd.md`
+- `release.md`（如果存在）
+
+缺失 `release.md` 时：
+
+- 在汇总中列入“未记录上线事项的任务”。
+- 默认不阻塞汇总。
+- 不要自动为这些任务生成 `release.md`；单任务记录由 finish-work skill override 注入块负责。
+
+## Step 3: 汇总分类
+
+生成操作单草案，按以下固定小节归并：
+
+```md
+# 上线操作单：<release-name>
+
+## 范围
+- 任务：<task>
+- 生成时间：<date>
+
+## SQL 变更
+- 无
+
+## 配置变更
+- 无
+
+## 批处理 / 部署脚本 / 数据修复
+- 无
+
+## 外部系统 / 依赖平台上线
+- 无
+
+## 上线顺序
+- 无特殊顺序
+
+## 回滚说明
+- 回滚代码即可
+
+## 上线后验证
+- 按任务验收标准验证
+
+## 未记录上线事项的任务
+- 无
+```
+
+分类规则：
+
+- SQL、migration、DDL、DML、数据库脚本放入“SQL 变更”。
+- 环境变量、配置中心、feature flag、权限、密钥、外部地址放入“配置变更”。
+- 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑放入“批处理 / 部署脚本 / 数据修复”。
+- H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统，放入“外部系统 / 依赖平台上线”。
+- 每条内容保留任务来源引用，例如 `[06-17-example-task]`。
+
+## Step 4: 写盘确认
+
+写入 `.trellis/releases/<release-name>.md` 前，展示：
+
+- 目标路径。
+- 纳入的任务列表。
+- 未记录上线事项的任务列表。
+- 草案摘要。
+
+等待用户明确确认后再写盘。用户要求调整范围、名称或内容时，先更新草案再重新确认。
+
+## Step 5: 输出结果
+
+写盘后报告：
+
+- 已生成的 release 文件路径。
+- 纳入任务数量。
+- 未记录上线事项任务数量。
+- 上线前仍需人工复核的事项。
+
+## 反模式
+
+- 自动执行 SQL、脚本、部署或外部系统操作。
+- 把缺失 `release.md` 的任务静默忽略。
+- 汇总时丢失任务来源引用。
+- 把 H0 接口中转平台等外部依赖混入普通配置变更。
+- 在用户确认前写入 `.trellis/releases/<release-name>.md`。

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

@@ -4,13 +4,14 @@ description: |
   Route trellis-implement / trellis-check execution mode with a gitignored personal preference file.
   Implement can route inline or subagent. Check defaults to check-all inline/subagent; lightweight
   trellis-check is hidden and only available when the user explicitly requests "light check" / "轻量检查".
-  Invoked from Phase 2.1 / 2.2 / 3.1 of the routing-aware workflow. Skip in non-trellis projects
+  Invoked from Phase 2.1 target=implement and Phase 2.2 target=check/check-all of the routing-aware workflow.
+  Phase 3.1 is final verification and does not normally route check again. Skip in non-trellis projects
   (no .trellis/). Not for other subagents (trellis-research / trellis-debug).
 ---
 
 # Trellis 路由器：implement / check 执行模式选择
 
-主 agent 进入 Phase 2.1 / 2.2 / 3.1 时调用本 skill，决定 implement / check 的执行模式。核心目标是减少重复打断：正常路由优先读取个人本地配置；用户要求临时改、重新选择或清除默认时，必须绕过配置并重新展示选项。
+主 agent 进入 Phase 2.1 的实现路由或 Phase 2.2 的检查路由时调用本 skill，决定 implement / check 的执行模式。Phase 3.1 属于最终确认节点，通常只确认 Phase 2.2 已通过，不作为普通 check route 入口。核心目标是减少重复打断：正常路由优先读取个人本地配置；用户要求临时改、重新选择或清除默认时，必须绕过配置并重新展示选项。
 
 个人配置只写入 `.trellis/.route-prefs.tmp`。该文件匹配 `.trellis/.gitignore` 的 `*.tmp` 规则，属于开发者本地偏好，不纳入 git，也不影响其他开发者。
 
@@ -18,7 +19,7 @@ description: |
 
 ## Step 0: 识别目标与用户意图
 
-个人 route 配置只决定“已获准执行后的模式”，不是开工授权。读取 `.trellis/.route-prefs.tmp` 前，必须确认当前 workflow 已允许进入对应 target：implement 需要任务已完成规划确认并处于 `in_progress`；check 需要已有本轮实现变更或用户明确要求检查。如果仍在 planning、等待用户确认，或用户表达“等一下 / 我再想想”，停止，不读取个人配置。
+个人 route 配置只决定“已获准执行后的模式”，不是开工授权。读取 `.trellis/.route-prefs.tmp` 前，必须确认当前 workflow 已允许进入对应 target：implement 需要任务已完成规划确认并处于 `in_progress`；check 用于 Phase 2.2 检查执行，或用户明确要求最终复查 / 轻量检查。Phase 3.1 只有在 Phase 2.2 结果缺失、check 后代码变更、风险较高或用户明确要求复查时才重新进入 check 路由。如果仍在 planning、等待用户确认，或用户表达“等一下 / 我再想想”，停止，不读取个人配置。
 
 Codex inline mode 只表示主会话默认直接执行，不是 route 选项过滤器。即使当前上下文出现 `<codex-mode>inline...do not dispatch...</codex-mode>` 或 `workflow-state:in_progress-inline`，也不能推断“只能 inline”或跳过 subagent 选项；仍必须读取 `.trellis/.route-prefs.tmp`，或在无有效配置时展示正常 inline/subagent 选项。若本 skill 的紧邻路由决定是 subagent，本步骤允许主 agent dispatch 对应 implement/check sub-agent；禁止的是绕过 `trellis-route` 直接 dispatch。