flower-trellis 0.3.1-beta.1 → 0.3.1-beta.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -1
- package/enhancements/0.6/.agents/skills/trellis-release/SKILL.md +80 -20
- package/enhancements/0.6/.agents/skills/trellis-route/SKILL.md +17 -7
- package/enhancements/0.6/.claude/skills/trellis-release/SKILL.md +80 -20
- package/enhancements/0.6/.claude/skills/trellis-route/SKILL.md +17 -7
- package/enhancements/0.6/overrides/skills/trellis-finish-work.md +21 -5
- package/enhancements/0.6/overrides/workflow-states/in_progress-inline.md +5 -3
- package/enhancements/0.6/overrides/workflow-states/in_progress.md +5 -5
- package/enhancements/0.6/overrides/workflow-states/no_task.md +5 -5
- package/enhancements/0.6/overrides/workflow.md +13 -14
- package/enhancements/MANIFEST.json +2 -2
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -106,7 +106,7 @@ flower banner → 平台多选菜单 → Trellis 原生交互(模板 / monorepo
|
|
|
106
106
|
- **统一品牌头部**:Trellis 子进程在伪终端(`node-pty`)中运行,其原生的模板 / monorepo / 冲突等交互完整保留,但重复打印的启动 banner 被过滤,全程只呈现一个 flower banner。
|
|
107
107
|
- **按平台铺设技能**:Claude 铺到 `.claude/skills`,Codex / Gemini 等铺到 `.agents/skills`;并对 codex 做后处理(兼容清理旧 `config.toml` 的 `[features.multi_agent_v2]`,在保留上游 hooks 的基础上补全 `SessionStart`)。
|
|
108
108
|
- **幂等执行**:`workflow.md` 注入前先按 `BEGIN/END` 标记清除旧块再重注入(块数恒定,不会翻倍,首次注入前备份 `.bak`);技能文件覆盖式铺设,并通过 `.trellis/.flower-manifest.json` 记录已铺路径,升级时删除已淘汰项。
|
|
109
|
-
- **上线事项账本**:强化包通过 finish-work skill override 在归档前智能识别 SQL、配置、批处理 / 部署脚本 / 数据修复、外部系统 / 依赖平台等上线事项,必要时写入任务 `release.md`;`trellis-release`
|
|
109
|
+
- **上线事项账本**:强化包通过 finish-work skill override 在归档前智能识别 SQL、配置、批处理 / 部署脚本 / 数据修复、外部系统 / 依赖平台等上线事项,必要时写入任务 `release.md`;`trellis-release` 可在正式上线前核对任务文档、`release.md` 和 git 证据,生成 `YYYY-MM-DD-<release-slug>.md` 格式的版本 / 批次操作单。
|
|
110
110
|
- **安全中止**:`Ctrl+C` 取消后不会继续叠加。
|
|
111
111
|
|
|
112
112
|
## 强化包与更新
|
|
@@ -1,21 +1,29 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: trellis-release
|
|
3
|
-
description: "
|
|
3
|
+
description: "核对并汇总 Trellis 任务 release.md，生成版本或上线批次操作单。用于正式上线前整理 SQL、配置、批处理、外部系统、回滚、验证事项和文档漂移风险。"
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
#
|
|
6
|
+
# 上线操作单汇总
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
核对并汇总一组 Trellis 任务的上线事项，生成版本 / 上线批次操作单：`.trellis/releases/<release-file>.md`。
|
|
9
9
|
|
|
10
|
-
本 skill
|
|
10
|
+
本 skill 只整理和核对上线事项，不执行上线、不提交代码、不推送代码。
|
|
11
11
|
|
|
12
12
|
## 适用场景
|
|
13
13
|
|
|
14
14
|
- 用户说“生成上线单”“汇总 release.md”“正式上线前整理操作单”。
|
|
15
15
|
- 用户说“版本上线总结”“汇总这些任务的上线事项”“trellis-release”。
|
|
16
16
|
- 用户需要把多个任务的 SQL、配置、批处理、外部系统上线、回滚和验证事项合成一份操作单。
|
|
17
|
+
- 用户担心任务文档、实现代码、提交记录或上下文压缩后发生文档漂移，需要上线前复核。
|
|
17
18
|
|
|
18
|
-
##
|
|
19
|
+
## 核心原则
|
|
20
|
+
|
|
21
|
+
- **先核对，再汇总**：不能只复制已有 `release.md`。必须对照任务文档、实现计划、检查记录和 git 证据判断上线事项是否完整。
|
|
22
|
+
- **文件证据优先**：即使刚经历上下文压缩、会话恢复或你“记得”之前做过什么，也必须重新读取本地文件和 git 证据。
|
|
23
|
+
- **不静默相信旧文档**：已有 `release.md` 只能作为输入之一。发现缺失、冲突、过期或证据不足时，在批次上线单里标记 `Needs human review`。
|
|
24
|
+
- **保留来源引用**：每条上线事项都要标注任务来源，例如 `[06-17-example-task]`。
|
|
25
|
+
|
|
26
|
+
## Step 1: 确定任务集合与 release 文件名
|
|
19
27
|
|
|
20
28
|
先读取本地任务目录，不要凭记忆回答：
|
|
21
29
|
|
|
@@ -31,27 +39,60 @@ python3 ./.trellis/scripts/task.py list-archive || true
|
|
|
31
39
|
- 如果用户给出版本名、日期范围、wave、批次名，从 `.trellis/tasks/` 和 `.trellis/tasks/archive/` 中匹配候选任务。
|
|
32
40
|
- 如果用户只说“当前版本”但没有足够上下文，先列出候选任务并问一个问题确认范围。
|
|
33
41
|
|
|
34
|
-
release
|
|
42
|
+
release 文件名生成规则：
|
|
35
43
|
|
|
36
|
-
-
|
|
37
|
-
-
|
|
38
|
-
-
|
|
44
|
+
- 用户显式给出文件名 / release 名称时，使用用户名称，并清理成安全文件名。
|
|
45
|
+
- 用户未给出时，使用 `YYYY-MM-DD-<release-slug>.md`。
|
|
46
|
+
- `<release-slug>` 优先来自用户给出的版本号、批次名、wave 名称；推导不到时使用 `release`。
|
|
47
|
+
- 示例：`2026-06-25-v0.3.1-beta.1.md`、`2026-06-25-h0-relay-batch.md`、`2026-06-25-release.md`。
|
|
48
|
+
- 文件名清理规则：转小写，空白替换为 `-`，移除路径分隔符和除字母、数字、点、下划线、短横线以外的字符，合并连续短横线，去掉首尾短横线。
|
|
49
|
+
- 输出路径固定为 `.trellis/releases/<release-file>.md`。
|
|
50
|
+
- 如果目标文件已存在，追加 `-2`、`-3` 等数字后缀，不能覆盖已有上线单。
|
|
39
51
|
|
|
40
|
-
## Step 2:
|
|
52
|
+
## Step 2: 读取任务材料和 git 证据
|
|
41
53
|
|
|
42
54
|
对每个任务读取：
|
|
43
55
|
|
|
44
56
|
- `task.json`
|
|
45
57
|
- `prd.md`
|
|
58
|
+
- `design.md`（如果存在）
|
|
59
|
+
- `implement.md`（如果存在）
|
|
60
|
+
- `implement.jsonl`
|
|
61
|
+
- `check.jsonl`
|
|
46
62
|
- `release.md`（如果存在）
|
|
47
63
|
|
|
48
|
-
|
|
64
|
+
同时读取可用的本地证据：
|
|
65
|
+
|
|
66
|
+
- `task.json` 中记录的提交、分支、相关文件和任务状态。
|
|
67
|
+
- 任务文档中明确提到的代码路径、配置路径、脚本路径和外部系统。
|
|
68
|
+
- 近期 work commit 的文件列表和 diff，例如 `git log --oneline --name-only -n 30`、`git show --name-only <hash>`。
|
|
69
|
+
- 当前 `git status --porcelain` / `git diff --name-only` 只作为风险提示；未提交 dirty path 不能直接当作已完成上线内容。
|
|
70
|
+
|
|
71
|
+
核对时重点搜索这些上线信号：
|
|
72
|
+
|
|
73
|
+
- SQL、migration、DDL、DML、数据库脚本。
|
|
74
|
+
- 环境变量、配置中心、feature flag、权限、密钥、外部地址。
|
|
75
|
+
- 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑。
|
|
76
|
+
- H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统。
|
|
77
|
+
- 回滚步骤、上线顺序、上线后验证要求。
|
|
78
|
+
|
|
79
|
+
## Step 3: 核对 release.md 漂移
|
|
49
80
|
|
|
50
|
-
|
|
51
|
-
- 默认不阻塞汇总。
|
|
52
|
-
- 不要自动为这些任务生成 `release.md`；单任务记录由 finish-work skill override 注入块负责。
|
|
81
|
+
对每个任务形成核对结论：
|
|
53
82
|
|
|
54
|
-
|
|
83
|
+
- `已覆盖`：已有 `release.md` 与任务材料、实现影响面和提交证据一致。
|
|
84
|
+
- `缺失 release.md`：任务没有 `release.md`，但批次上线单仍要记录核对结果。
|
|
85
|
+
- `疑似漂移`：已有 `release.md` 与任务材料 / 提交证据不一致，或明显遗漏上线信号。
|
|
86
|
+
- `Needs human review`：证据不足、上下文不完整、dirty path 影响判断，或无法确认外部系统是否已处理。
|
|
87
|
+
|
|
88
|
+
处理规则：
|
|
89
|
+
|
|
90
|
+
- 缺失 `release.md` 时，在汇总中列入“未记录上线事项的任务”，并写明从其他证据核对出的事项或风险。
|
|
91
|
+
- 不要自动为这些任务生成单任务 `release.md`；单任务记录由 finish-work skill override 注入块负责。
|
|
92
|
+
- 已有 `release.md` 发生漂移时，不要静默改写原任务文件；在批次上线单的“风险标记 / 需人工复核”中记录差异。
|
|
93
|
+
- 如果无法高置信判断某项是否需要上线操作，保留为 `Needs human review`，不要写成“无”。
|
|
94
|
+
|
|
95
|
+
## Step 4: 汇总分类
|
|
55
96
|
|
|
56
97
|
生成操作单草案，按以下固定小节归并：
|
|
57
98
|
|
|
@@ -59,8 +100,18 @@ release 名称生成规则：
|
|
|
59
100
|
# 上线操作单：<release-name>
|
|
60
101
|
|
|
61
102
|
## 范围
|
|
62
|
-
-
|
|
103
|
+
- 文件：.trellis/releases/<release-file>.md
|
|
63
104
|
- 生成时间：<date>
|
|
105
|
+
- 任务：
|
|
106
|
+
- <task>
|
|
107
|
+
|
|
108
|
+
## 核对摘要
|
|
109
|
+
| 任务 | release.md | 核对证据 | 结论 |
|
|
110
|
+
| --- | --- | --- | --- |
|
|
111
|
+
| <task> | 存在 / 缺失 | prd / implement / check / git | 已覆盖 / 缺失 release.md / 疑似漂移 / Needs human review |
|
|
112
|
+
|
|
113
|
+
## 风险标记 / 需人工复核
|
|
114
|
+
- 无
|
|
64
115
|
|
|
65
116
|
## SQL 变更
|
|
66
117
|
- 无
|
|
@@ -93,32 +144,41 @@ release 名称生成规则：
|
|
|
93
144
|
- 环境变量、配置中心、feature flag、权限、密钥、外部地址放入“配置变更”。
|
|
94
145
|
- 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑放入“批处理 / 部署脚本 / 数据修复”。
|
|
95
146
|
- H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统，放入“外部系统 / 依赖平台上线”。
|
|
147
|
+
- 回滚和验证不能只写模板默认值；如果任务材料或 git 证据显示存在特殊回滚 / 验证要求，必须覆盖默认项。
|
|
96
148
|
- 每条内容保留任务来源引用，例如 `[06-17-example-task]`。
|
|
97
149
|
|
|
98
|
-
## Step
|
|
150
|
+
## Step 5: 写盘确认
|
|
99
151
|
|
|
100
|
-
写入 `.trellis/releases/<release-
|
|
152
|
+
写入 `.trellis/releases/<release-file>.md` 前，展示：
|
|
101
153
|
|
|
102
154
|
- 目标路径。
|
|
103
155
|
- 纳入的任务列表。
|
|
156
|
+
- 文件名生成依据和冲突处理结果。
|
|
157
|
+
- 每个任务的核对结论。
|
|
104
158
|
- 未记录上线事项的任务列表。
|
|
159
|
+
- 漂移 / 风险 / 需人工复核列表。
|
|
105
160
|
- 草案摘要。
|
|
106
161
|
|
|
107
162
|
等待用户明确确认后再写盘。用户要求调整范围、名称或内容时，先更新草案再重新确认。
|
|
108
163
|
|
|
109
|
-
## Step
|
|
164
|
+
## Step 6: 输出结果
|
|
110
165
|
|
|
111
166
|
写盘后报告：
|
|
112
167
|
|
|
113
168
|
- 已生成的 release 文件路径。
|
|
114
169
|
- 纳入任务数量。
|
|
115
170
|
- 未记录上线事项任务数量。
|
|
171
|
+
- `疑似漂移` / `Needs human review` 数量。
|
|
116
172
|
- 上线前仍需人工复核的事项。
|
|
117
173
|
|
|
118
174
|
## 反模式
|
|
119
175
|
|
|
120
176
|
- 自动执行 SQL、脚本、部署或外部系统操作。
|
|
177
|
+
- 只汇总已有 `release.md`，不核对任务材料和 git 证据。
|
|
178
|
+
- 上下文压缩或会话恢复后依赖记忆判断上线事项。
|
|
121
179
|
- 把缺失 `release.md` 的任务静默忽略。
|
|
180
|
+
- 发现旧 `release.md` 与实现证据不一致时仍写“无风险”。
|
|
122
181
|
- 汇总时丢失任务来源引用。
|
|
123
182
|
- 把 H0 接口中转平台等外部依赖混入普通配置变更。
|
|
124
|
-
- 在用户确认前写入 `.trellis/releases/<release-
|
|
183
|
+
- 在用户确认前写入 `.trellis/releases/<release-file>.md`。
|
|
184
|
+
- 覆盖已有 `.trellis/releases/` 文件。
|
|
@@ -5,14 +5,14 @@ description: |
|
|
|
5
5
|
Implement can route inline or subagent. Check defaults to check-all inline/subagent; lightweight
|
|
6
6
|
trellis-check is hidden and only available when the user explicitly requests "light check" / "轻量检查".
|
|
7
7
|
Invoked from Phase 2.1 target=implement and Phase 2.2 target=check/check-all of the routing-aware workflow.
|
|
8
|
-
|
|
8
|
+
Current-task repair/recheck loops reuse the latest valid route decision instead of prompting again.
|
|
9
9
|
Final re-checks return to Phase 2.2 before commit.
|
|
10
10
|
Skip in non-trellis projects (no .trellis/). Not for other subagents (trellis-research / trellis-debug).
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
# Trellis 路由器：implement / check 执行模式选择
|
|
14
14
|
|
|
15
|
-
主 agent 进入 Phase 2.1 实现路由或 Phase 2.2 检查路由时调用本 skill
|
|
15
|
+
主 agent 进入 Phase 2.1 实现路由或 Phase 2.2 检查路由时调用本 skill。当前任务内已有合法来源的最近 route 决策时，后续实现、修复、重检默认复用该决策；没有合法决策时才进入本 skill 或同编号 fallback。提交前确实需要最终复查时，回到 Phase 2.2 并复用当前任务的合法 check route，除非用户明确要求重选。
|
|
16
16
|
|
|
17
17
|
个人配置只写入 `.trellis/.route-prefs.tmp`。该文件匹配 `.trellis/.gitignore` 的 `*.tmp` 规则，属于开发者本地偏好，不纳入 git，也不影响其他开发者。
|
|
18
18
|
|
|
@@ -20,9 +20,11 @@ description: |
|
|
|
20
20
|
|
|
21
21
|
## Step 0: 识别目标与用户意图
|
|
22
22
|
|
|
23
|
-
个人 route 配置只决定“已获准执行后的模式”，不是开工授权。读取 `.trellis/.route-prefs.tmp` 前，必须确认当前 workflow 已允许进入对应 target：implement 需要任务已完成规划确认并处于 `in_progress`；check 用于 Phase 2.2
|
|
23
|
+
个人 route 配置只决定“已获准执行后的模式”，不是开工授权。读取 `.trellis/.route-prefs.tmp` 前，必须确认当前 workflow 已允许进入对应 target：implement 需要任务已完成规划确认并处于 `in_progress`；check 用于 Phase 2.2 检查执行，或用户明确要求最终复查 / 轻量检查。最终复查只有在 Phase 2.2 结果缺失、风险较高或用户明确要求复查时才回到 Phase 2.2；回到 Phase 2.2 后优先复用当前任务的合法 check route，除非用户明确要求重选/临时改/清除默认。如果仍在 planning、等待用户确认，或用户表达“等一下 / 我再想想”，停止，不读取个人配置。
|
|
24
24
|
|
|
25
|
-
|
|
25
|
+
合法 route 决策必须能追溯到 `trellis-route`、同编号 fallback 选项，或由本 skill 读取到的有效 `.trellis/.route-prefs.tmp` 配置。用户自然语言说过“inline/subagent”、compact summary、SessionStart 摘要、`codex-mode`、空 `.route-prefs.tmp`、旧单值偏好，都不能单独作为有效 route 决策。
|
|
26
|
+
|
|
27
|
+
当前任务内已有 target 匹配且来源合法的 route 决策时，后续实现、check 发现问题、用户指出刚检查过的实现有问题、修复后重检、提交前复查均默认复用最近 implement/check 路由；除非用户明确要求重选/临时改/清除默认，不再调用本 skill。
|
|
26
28
|
|
|
27
29
|
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。
|
|
28
30
|
|
|
@@ -224,6 +226,13 @@ OLD_CHECK=$(awk -F= '$1=="check"{print $2}' "$PREF_FILE" 2>/dev/null | tail -n 1
|
|
|
224
226
|
[来自个人 route 配置：`.trellis/.route-prefs.tmp` (<key>=<value>)。]
|
|
225
227
|
[说明：用户明确请求轻量检查，使用隐藏逃生口。]
|
|
226
228
|
|
|
229
|
+
route_decision:
|
|
230
|
+
target: <implement | check>
|
|
231
|
+
mode: <inline | subagent | check-all-inline | check-all-subagent | check-inline | check-subagent>
|
|
232
|
+
source: <trellis-route | route-prefs | numbered-fallback>
|
|
233
|
+
scope: task
|
|
234
|
+
task: <task.py current 的任务路径或 current>
|
|
235
|
+
|
|
227
236
|
接下来主 agent 应当：
|
|
228
237
|
- <路由表里对应的工具调用形式>
|
|
229
238
|
- [若 implement subagent 且 subagent_skip_compile=true：附加“跳过编译”prompt 段]
|
|
@@ -232,7 +241,7 @@ OLD_CHECK=$(awk -F= '$1=="check"{print $2}' "$PREF_FILE" 2>/dev/null | tail -n 1
|
|
|
232
241
|
- <要避免的工具调用>
|
|
233
242
|
```
|
|
234
243
|
|
|
235
|
-
中括号内行为条件性出现：仅命中个人配置时显示配置行；仅轻量 check 时显示隐藏逃生口说明；仅 implement subagent + skip_compile=true
|
|
244
|
+
中括号内行为条件性出现：仅命中个人配置时显示配置行；仅轻量 check 时显示隐藏逃生口说明；仅 implement subagent + skip_compile=true 时附加“跳过编译”段。`route_decision` 必须保留在回复、交接摘要或 compact summary 中；没有 `source` 的自然语言偏好不能被后续 agent 复用为 route。
|
|
236
245
|
|
|
237
246
|
---
|
|
238
247
|
|
|
@@ -241,7 +250,7 @@ OLD_CHECK=$(awk -F= '$1=="check"{print $2}' "$PREF_FILE" 2>/dev/null | tail -n 1
|
|
|
241
250
|
1. **个人配置私有**：`.trellis/.route-prefs.tmp` 是本地偏好，gitignored，不能进入提交计划。
|
|
242
251
|
2. **正常路由少打断**：命中个人配置时直接输出路由决定，不再重复询问。
|
|
243
252
|
3. **显式覆盖优先于配置**：用户要求临时改、重新选择或清除默认时，必须重新展示选项，不能让配置优先。
|
|
244
|
-
4.
|
|
253
|
+
4. **当前任务复用路由**：当前任务内已有合法来源的最近 implement/check 路由时，后续实现、修复、重检和复查默认沿用，不再次询问模式。
|
|
245
254
|
5. **check 默认全面检查**：普通 check 路由只展示 `check-all` inline/subagent，不推荐轻量 `trellis-check`。
|
|
246
255
|
6. **轻量 check 是隐藏逃生口**：只有用户明确请求 `light check` / `轻量检查` 时才可走轻量 `trellis-check`。
|
|
247
256
|
7. **决策与执行分离**：本 skill 只输出指令，下一轮由主 agent 调工具。
|
|
@@ -259,7 +268,8 @@ OLD_CHECK=$(awk -F= '$1=="check"{print $2}' "$PREF_FILE" 2>/dev/null | tail -n 1
|
|
|
259
268
|
- 没有用户明确请求时，把 check 降级到轻量 `trellis-check`。
|
|
260
269
|
- `AskUserQuestion` / `request_user_input` 不可用时，记录为 inline 或 subagent 路径并继续。
|
|
261
270
|
- 没有有效 check 配置、用户选择或最近本轮 check 路由决定时，自动执行 inline check。
|
|
262
|
-
-
|
|
271
|
+
- 没有 `source` 合法的 `route_decision`，就把“用户说过 inline/subagent”或 compact summary 当成已路由。
|
|
272
|
+
- check 发现问题后，把当前任务内已有合法 route 的修复/重检当成新的 route 边界再次询问模式。
|
|
263
273
|
- 给 check 任何模式附加“跳过编译”指令。
|
|
264
274
|
- 询问后忽视用户答案默认 subagent。
|
|
265
275
|
- 因 `<codex-mode>` 或 `in_progress-inline` 提到 inline，就自行把无配置 route 结果改成 inline 或隐藏 subagent 选项。
|
|
@@ -1,21 +1,29 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: trellis-release
|
|
3
|
-
description: "
|
|
3
|
+
description: "核对并汇总 Trellis 任务 release.md，生成版本或上线批次操作单。用于正式上线前整理 SQL、配置、批处理、外部系统、回滚、验证事项和文档漂移风险。"
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
#
|
|
6
|
+
# 上线操作单汇总
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
核对并汇总一组 Trellis 任务的上线事项，生成版本 / 上线批次操作单：`.trellis/releases/<release-file>.md`。
|
|
9
9
|
|
|
10
|
-
本 skill
|
|
10
|
+
本 skill 只整理和核对上线事项，不执行上线、不提交代码、不推送代码。
|
|
11
11
|
|
|
12
12
|
## 适用场景
|
|
13
13
|
|
|
14
14
|
- 用户说“生成上线单”“汇总 release.md”“正式上线前整理操作单”。
|
|
15
15
|
- 用户说“版本上线总结”“汇总这些任务的上线事项”“trellis-release”。
|
|
16
16
|
- 用户需要把多个任务的 SQL、配置、批处理、外部系统上线、回滚和验证事项合成一份操作单。
|
|
17
|
+
- 用户担心任务文档、实现代码、提交记录或上下文压缩后发生文档漂移，需要上线前复核。
|
|
17
18
|
|
|
18
|
-
##
|
|
19
|
+
## 核心原则
|
|
20
|
+
|
|
21
|
+
- **先核对，再汇总**：不能只复制已有 `release.md`。必须对照任务文档、实现计划、检查记录和 git 证据判断上线事项是否完整。
|
|
22
|
+
- **文件证据优先**：即使刚经历上下文压缩、会话恢复或你“记得”之前做过什么，也必须重新读取本地文件和 git 证据。
|
|
23
|
+
- **不静默相信旧文档**：已有 `release.md` 只能作为输入之一。发现缺失、冲突、过期或证据不足时，在批次上线单里标记 `Needs human review`。
|
|
24
|
+
- **保留来源引用**：每条上线事项都要标注任务来源，例如 `[06-17-example-task]`。
|
|
25
|
+
|
|
26
|
+
## Step 1: 确定任务集合与 release 文件名
|
|
19
27
|
|
|
20
28
|
先读取本地任务目录，不要凭记忆回答：
|
|
21
29
|
|
|
@@ -31,27 +39,60 @@ python3 ./.trellis/scripts/task.py list-archive || true
|
|
|
31
39
|
- 如果用户给出版本名、日期范围、wave、批次名，从 `.trellis/tasks/` 和 `.trellis/tasks/archive/` 中匹配候选任务。
|
|
32
40
|
- 如果用户只说“当前版本”但没有足够上下文，先列出候选任务并问一个问题确认范围。
|
|
33
41
|
|
|
34
|
-
release
|
|
42
|
+
release 文件名生成规则：
|
|
35
43
|
|
|
36
|
-
-
|
|
37
|
-
-
|
|
38
|
-
-
|
|
44
|
+
- 用户显式给出文件名 / release 名称时，使用用户名称，并清理成安全文件名。
|
|
45
|
+
- 用户未给出时，使用 `YYYY-MM-DD-<release-slug>.md`。
|
|
46
|
+
- `<release-slug>` 优先来自用户给出的版本号、批次名、wave 名称；推导不到时使用 `release`。
|
|
47
|
+
- 示例：`2026-06-25-v0.3.1-beta.1.md`、`2026-06-25-h0-relay-batch.md`、`2026-06-25-release.md`。
|
|
48
|
+
- 文件名清理规则：转小写，空白替换为 `-`，移除路径分隔符和除字母、数字、点、下划线、短横线以外的字符，合并连续短横线，去掉首尾短横线。
|
|
49
|
+
- 输出路径固定为 `.trellis/releases/<release-file>.md`。
|
|
50
|
+
- 如果目标文件已存在，追加 `-2`、`-3` 等数字后缀，不能覆盖已有上线单。
|
|
39
51
|
|
|
40
|
-
## Step 2:
|
|
52
|
+
## Step 2: 读取任务材料和 git 证据
|
|
41
53
|
|
|
42
54
|
对每个任务读取：
|
|
43
55
|
|
|
44
56
|
- `task.json`
|
|
45
57
|
- `prd.md`
|
|
58
|
+
- `design.md`（如果存在）
|
|
59
|
+
- `implement.md`（如果存在）
|
|
60
|
+
- `implement.jsonl`
|
|
61
|
+
- `check.jsonl`
|
|
46
62
|
- `release.md`（如果存在）
|
|
47
63
|
|
|
48
|
-
|
|
64
|
+
同时读取可用的本地证据：
|
|
65
|
+
|
|
66
|
+
- `task.json` 中记录的提交、分支、相关文件和任务状态。
|
|
67
|
+
- 任务文档中明确提到的代码路径、配置路径、脚本路径和外部系统。
|
|
68
|
+
- 近期 work commit 的文件列表和 diff，例如 `git log --oneline --name-only -n 30`、`git show --name-only <hash>`。
|
|
69
|
+
- 当前 `git status --porcelain` / `git diff --name-only` 只作为风险提示；未提交 dirty path 不能直接当作已完成上线内容。
|
|
70
|
+
|
|
71
|
+
核对时重点搜索这些上线信号：
|
|
72
|
+
|
|
73
|
+
- SQL、migration、DDL、DML、数据库脚本。
|
|
74
|
+
- 环境变量、配置中心、feature flag、权限、密钥、外部地址。
|
|
75
|
+
- 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑。
|
|
76
|
+
- H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统。
|
|
77
|
+
- 回滚步骤、上线顺序、上线后验证要求。
|
|
78
|
+
|
|
79
|
+
## Step 3: 核对 release.md 漂移
|
|
49
80
|
|
|
50
|
-
|
|
51
|
-
- 默认不阻塞汇总。
|
|
52
|
-
- 不要自动为这些任务生成 `release.md`；单任务记录由 finish-work skill override 注入块负责。
|
|
81
|
+
对每个任务形成核对结论：
|
|
53
82
|
|
|
54
|
-
|
|
83
|
+
- `已覆盖`：已有 `release.md` 与任务材料、实现影响面和提交证据一致。
|
|
84
|
+
- `缺失 release.md`：任务没有 `release.md`，但批次上线单仍要记录核对结果。
|
|
85
|
+
- `疑似漂移`：已有 `release.md` 与任务材料 / 提交证据不一致，或明显遗漏上线信号。
|
|
86
|
+
- `Needs human review`：证据不足、上下文不完整、dirty path 影响判断，或无法确认外部系统是否已处理。
|
|
87
|
+
|
|
88
|
+
处理规则：
|
|
89
|
+
|
|
90
|
+
- 缺失 `release.md` 时，在汇总中列入“未记录上线事项的任务”，并写明从其他证据核对出的事项或风险。
|
|
91
|
+
- 不要自动为这些任务生成单任务 `release.md`；单任务记录由 finish-work skill override 注入块负责。
|
|
92
|
+
- 已有 `release.md` 发生漂移时，不要静默改写原任务文件；在批次上线单的“风险标记 / 需人工复核”中记录差异。
|
|
93
|
+
- 如果无法高置信判断某项是否需要上线操作，保留为 `Needs human review`，不要写成“无”。
|
|
94
|
+
|
|
95
|
+
## Step 4: 汇总分类
|
|
55
96
|
|
|
56
97
|
生成操作单草案，按以下固定小节归并：
|
|
57
98
|
|
|
@@ -59,8 +100,18 @@ release 名称生成规则：
|
|
|
59
100
|
# 上线操作单：<release-name>
|
|
60
101
|
|
|
61
102
|
## 范围
|
|
62
|
-
-
|
|
103
|
+
- 文件：.trellis/releases/<release-file>.md
|
|
63
104
|
- 生成时间：<date>
|
|
105
|
+
- 任务：
|
|
106
|
+
- <task>
|
|
107
|
+
|
|
108
|
+
## 核对摘要
|
|
109
|
+
| 任务 | release.md | 核对证据 | 结论 |
|
|
110
|
+
| --- | --- | --- | --- |
|
|
111
|
+
| <task> | 存在 / 缺失 | prd / implement / check / git | 已覆盖 / 缺失 release.md / 疑似漂移 / Needs human review |
|
|
112
|
+
|
|
113
|
+
## 风险标记 / 需人工复核
|
|
114
|
+
- 无
|
|
64
115
|
|
|
65
116
|
## SQL 变更
|
|
66
117
|
- 无
|
|
@@ -93,32 +144,41 @@ release 名称生成规则：
|
|
|
93
144
|
- 环境变量、配置中心、feature flag、权限、密钥、外部地址放入“配置变更”。
|
|
94
145
|
- 部署脚本、一次性命令、数据修复、定时任务触发、后台任务重跑放入“批处理 / 部署脚本 / 数据修复”。
|
|
95
146
|
- H0 接口中转平台、网关、消息平台、第三方管理后台等不在当前代码仓内但需要配合上线的系统，放入“外部系统 / 依赖平台上线”。
|
|
147
|
+
- 回滚和验证不能只写模板默认值；如果任务材料或 git 证据显示存在特殊回滚 / 验证要求，必须覆盖默认项。
|
|
96
148
|
- 每条内容保留任务来源引用，例如 `[06-17-example-task]`。
|
|
97
149
|
|
|
98
|
-
## Step
|
|
150
|
+
## Step 5: 写盘确认
|
|
99
151
|
|
|
100
|
-
写入 `.trellis/releases/<release-
|
|
152
|
+
写入 `.trellis/releases/<release-file>.md` 前，展示：
|
|
101
153
|
|
|
102
154
|
- 目标路径。
|
|
103
155
|
- 纳入的任务列表。
|
|
156
|
+
- 文件名生成依据和冲突处理结果。
|
|
157
|
+
- 每个任务的核对结论。
|
|
104
158
|
- 未记录上线事项的任务列表。
|
|
159
|
+
- 漂移 / 风险 / 需人工复核列表。
|
|
105
160
|
- 草案摘要。
|
|
106
161
|
|
|
107
162
|
等待用户明确确认后再写盘。用户要求调整范围、名称或内容时，先更新草案再重新确认。
|
|
108
163
|
|
|
109
|
-
## Step
|
|
164
|
+
## Step 6: 输出结果
|
|
110
165
|
|
|
111
166
|
写盘后报告：
|
|
112
167
|
|
|
113
168
|
- 已生成的 release 文件路径。
|
|
114
169
|
- 纳入任务数量。
|
|
115
170
|
- 未记录上线事项任务数量。
|
|
171
|
+
- `疑似漂移` / `Needs human review` 数量。
|
|
116
172
|
- 上线前仍需人工复核的事项。
|
|
117
173
|
|
|
118
174
|
## 反模式
|
|
119
175
|
|
|
120
176
|
- 自动执行 SQL、脚本、部署或外部系统操作。
|
|
177
|
+
- 只汇总已有 `release.md`，不核对任务材料和 git 证据。
|
|
178
|
+
- 上下文压缩或会话恢复后依赖记忆判断上线事项。
|
|
121
179
|
- 把缺失 `release.md` 的任务静默忽略。
|
|
180
|
+
- 发现旧 `release.md` 与实现证据不一致时仍写“无风险”。
|
|
122
181
|
- 汇总时丢失任务来源引用。
|
|
123
182
|
- 把 H0 接口中转平台等外部依赖混入普通配置变更。
|
|
124
|
-
- 在用户确认前写入 `.trellis/releases/<release-
|
|
183
|
+
- 在用户确认前写入 `.trellis/releases/<release-file>.md`。
|
|
184
|
+
- 覆盖已有 `.trellis/releases/` 文件。
|
|
@@ -5,14 +5,14 @@ description: |
|
|
|
5
5
|
Implement can route inline or subagent. Check defaults to check-all inline/subagent; lightweight
|
|
6
6
|
trellis-check is hidden and only available when the user explicitly requests "light check" / "轻量检查".
|
|
7
7
|
Invoked from Phase 2.1 target=implement and Phase 2.2 target=check/check-all of the routing-aware workflow.
|
|
8
|
-
|
|
8
|
+
Current-task repair/recheck loops reuse the latest valid route decision instead of prompting again.
|
|
9
9
|
Final re-checks return to Phase 2.2 before commit.
|
|
10
10
|
Skip in non-trellis projects (no .trellis/). Not for other subagents (trellis-research / trellis-debug).
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
# Trellis 路由器：implement / check 执行模式选择
|
|
14
14
|
|
|
15
|
-
主 agent 进入 Phase 2.1 实现路由或 Phase 2.2 检查路由时调用本 skill
|
|
15
|
+
主 agent 进入 Phase 2.1 实现路由或 Phase 2.2 检查路由时调用本 skill。当前任务内已有合法来源的最近 route 决策时，后续实现、修复、重检默认复用该决策；没有合法决策时才进入本 skill 或同编号 fallback。提交前确实需要最终复查时，回到 Phase 2.2 并复用当前任务的合法 check route，除非用户明确要求重选。
|
|
16
16
|
|
|
17
17
|
个人配置只写入 `.trellis/.route-prefs.tmp`。该文件匹配 `.trellis/.gitignore` 的 `*.tmp` 规则，属于开发者本地偏好，不纳入 git，也不影响其他开发者。
|
|
18
18
|
|
|
@@ -20,9 +20,11 @@ description: |
|
|
|
20
20
|
|
|
21
21
|
## Step 0: 识别目标与用户意图
|
|
22
22
|
|
|
23
|
-
个人 route 配置只决定“已获准执行后的模式”，不是开工授权。读取 `.trellis/.route-prefs.tmp` 前，必须确认当前 workflow 已允许进入对应 target：implement 需要任务已完成规划确认并处于 `in_progress`；check 用于 Phase 2.2
|
|
23
|
+
个人 route 配置只决定“已获准执行后的模式”，不是开工授权。读取 `.trellis/.route-prefs.tmp` 前，必须确认当前 workflow 已允许进入对应 target：implement 需要任务已完成规划确认并处于 `in_progress`；check 用于 Phase 2.2 检查执行，或用户明确要求最终复查 / 轻量检查。最终复查只有在 Phase 2.2 结果缺失、风险较高或用户明确要求复查时才回到 Phase 2.2；回到 Phase 2.2 后优先复用当前任务的合法 check route，除非用户明确要求重选/临时改/清除默认。如果仍在 planning、等待用户确认，或用户表达“等一下 / 我再想想”，停止，不读取个人配置。
|
|
24
24
|
|
|
25
|
-
|
|
25
|
+
合法 route 决策必须能追溯到 `trellis-route`、同编号 fallback 选项，或由本 skill 读取到的有效 `.trellis/.route-prefs.tmp` 配置。用户自然语言说过“inline/subagent”、compact summary、SessionStart 摘要、`codex-mode`、空 `.route-prefs.tmp`、旧单值偏好，都不能单独作为有效 route 决策。
|
|
26
|
+
|
|
27
|
+
当前任务内已有 target 匹配且来源合法的 route 决策时，后续实现、check 发现问题、用户指出刚检查过的实现有问题、修复后重检、提交前复查均默认复用最近 implement/check 路由；除非用户明确要求重选/临时改/清除默认，不再调用本 skill。
|
|
26
28
|
|
|
27
29
|
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。
|
|
28
30
|
|
|
@@ -224,6 +226,13 @@ OLD_CHECK=$(awk -F= '$1=="check"{print $2}' "$PREF_FILE" 2>/dev/null | tail -n 1
|
|
|
224
226
|
[来自个人 route 配置：`.trellis/.route-prefs.tmp` (<key>=<value>)。]
|
|
225
227
|
[说明：用户明确请求轻量检查，使用隐藏逃生口。]
|
|
226
228
|
|
|
229
|
+
route_decision:
|
|
230
|
+
target: <implement | check>
|
|
231
|
+
mode: <inline | subagent | check-all-inline | check-all-subagent | check-inline | check-subagent>
|
|
232
|
+
source: <trellis-route | route-prefs | numbered-fallback>
|
|
233
|
+
scope: task
|
|
234
|
+
task: <task.py current 的任务路径或 current>
|
|
235
|
+
|
|
227
236
|
接下来主 agent 应当：
|
|
228
237
|
- <路由表里对应的工具调用形式>
|
|
229
238
|
- [若 implement subagent 且 subagent_skip_compile=true：附加“跳过编译”prompt 段]
|
|
@@ -232,7 +241,7 @@ OLD_CHECK=$(awk -F= '$1=="check"{print $2}' "$PREF_FILE" 2>/dev/null | tail -n 1
|
|
|
232
241
|
- <要避免的工具调用>
|
|
233
242
|
```
|
|
234
243
|
|
|
235
|
-
中括号内行为条件性出现：仅命中个人配置时显示配置行；仅轻量 check 时显示隐藏逃生口说明；仅 implement subagent + skip_compile=true
|
|
244
|
+
中括号内行为条件性出现：仅命中个人配置时显示配置行；仅轻量 check 时显示隐藏逃生口说明；仅 implement subagent + skip_compile=true 时附加“跳过编译”段。`route_decision` 必须保留在回复、交接摘要或 compact summary 中；没有 `source` 的自然语言偏好不能被后续 agent 复用为 route。
|
|
236
245
|
|
|
237
246
|
---
|
|
238
247
|
|
|
@@ -241,7 +250,7 @@ OLD_CHECK=$(awk -F= '$1=="check"{print $2}' "$PREF_FILE" 2>/dev/null | tail -n 1
|
|
|
241
250
|
1. **个人配置私有**：`.trellis/.route-prefs.tmp` 是本地偏好，gitignored，不能进入提交计划。
|
|
242
251
|
2. **正常路由少打断**：命中个人配置时直接输出路由决定，不再重复询问。
|
|
243
252
|
3. **显式覆盖优先于配置**：用户要求临时改、重新选择或清除默认时，必须重新展示选项，不能让配置优先。
|
|
244
|
-
4.
|
|
253
|
+
4. **当前任务复用路由**：当前任务内已有合法来源的最近 implement/check 路由时，后续实现、修复、重检和复查默认沿用，不再次询问模式。
|
|
245
254
|
5. **check 默认全面检查**：普通 check 路由只展示 `check-all` inline/subagent，不推荐轻量 `trellis-check`。
|
|
246
255
|
6. **轻量 check 是隐藏逃生口**：只有用户明确请求 `light check` / `轻量检查` 时才可走轻量 `trellis-check`。
|
|
247
256
|
7. **决策与执行分离**：本 skill 只输出指令，下一轮由主 agent 调工具。
|
|
@@ -259,7 +268,8 @@ OLD_CHECK=$(awk -F= '$1=="check"{print $2}' "$PREF_FILE" 2>/dev/null | tail -n 1
|
|
|
259
268
|
- 没有用户明确请求时，把 check 降级到轻量 `trellis-check`。
|
|
260
269
|
- `AskUserQuestion` / `request_user_input` 不可用时，记录为 inline 或 subagent 路径并继续。
|
|
261
270
|
- 没有有效 check 配置、用户选择或最近本轮 check 路由决定时，自动执行 inline check。
|
|
262
|
-
-
|
|
271
|
+
- 没有 `source` 合法的 `route_decision`，就把“用户说过 inline/subagent”或 compact summary 当成已路由。
|
|
272
|
+
- check 发现问题后，把当前任务内已有合法 route 的修复/重检当成新的 route 边界再次询问模式。
|
|
263
273
|
- 给 check 任何模式附加“跳过编译”指令。
|
|
264
274
|
- 询问后忽视用户答案默认 subagent。
|
|
265
275
|
- 因 `<codex-mode>` 或 `in_progress-inline` 提到 inline，就自行把无配置 route 结果改成 inline 或隐藏 subagent 选项。
|
|
@@ -10,23 +10,37 @@ Run this step after finish-work Step 2 dirty-path classification succeeds and be
|
|
|
10
10
|
|
|
11
11
|
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.
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
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.
|
|
14
14
|
|
|
15
|
-
|
|
15
|
+
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.
|
|
16
|
+
|
|
17
|
+
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`.
|
|
18
|
+
|
|
19
|
+
If no `release.md` exists:
|
|
16
20
|
|
|
17
21
|
- High-confidence release work exists: write `<task>/release.md`.
|
|
18
|
-
- High-confidence no release work exists: do not create `release.md`; mention in the final finish-work report that no release operations were identified.
|
|
22
|
+
- 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.
|
|
19
23
|
- Signals are uncertain but release risk exists: write `<task>/release.md` and mark the conclusion as `Needs human review`.
|
|
20
24
|
|
|
21
25
|
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.
|
|
22
26
|
|
|
23
|
-
When writing `release.md`, use this structure:
|
|
27
|
+
When writing or updating `release.md`, use this structure:
|
|
24
28
|
|
|
25
29
|
```markdown
|
|
26
30
|
# Release Operations
|
|
27
31
|
|
|
28
32
|
## Conclusion
|
|
29
|
-
Release operations exist. / Needs human review.
|
|
33
|
+
Release operations exist. / No release operations identified. / Needs human review.
|
|
34
|
+
|
|
35
|
+
## Evidence Checked
|
|
36
|
+
- task.json
|
|
37
|
+
- prd.md
|
|
38
|
+
- design.md / implement.md / implement.jsonl / check.jsonl
|
|
39
|
+
- release.md
|
|
40
|
+
- git commits / changed files
|
|
41
|
+
|
|
42
|
+
## Drift Check
|
|
43
|
+
Existing release.md is accurate. / Missing release.md. / Drift suspected. / Needs human review.
|
|
30
44
|
|
|
31
45
|
## SQL Changes
|
|
32
46
|
None
|
|
@@ -52,6 +66,8 @@ Verify according to task acceptance criteria.
|
|
|
52
66
|
|
|
53
67
|
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`.
|
|
54
68
|
|
|
69
|
+
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.
|
|
70
|
+
|
|
55
71
|
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.
|
|
56
72
|
|
|
57
73
|
<!-- END skill-garden skill override trellis-finish-work v0.6 -->
|
|
@@ -1,8 +1,10 @@
|
|
|
1
1
|
<!-- BEGIN skill-garden workflow-state in_progress_inline v0.6 -->
|
|
2
2
|
HIGHEST PRIORITY SKILL-GARDEN STATE GUARD (in_progress-inline):
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
3
|
+
This state block is a breadcrumb; the top-level skill-garden hub is the source of truth for route details.
|
|
4
|
+
Inline workflow-state is not an inline route decision. At Phase 2.1/2.2, reuse a valid current-task `route_decision` for the target when it exists; otherwise run `trellis-route(implement|check)` or ask the numbered fallback choices and wait.
|
|
5
|
+
A valid route decision must come from `trellis-route`, `numbered-fallback`, or `route-prefs` read by `trellis-route`; prose, compact/SessionStart summaries, `codex-mode`, empty prefs, and old single-value prefs are not enough.
|
|
6
|
+
Reuse the valid current-task route through later implementation, repair, recheck, and final re-check; reroute only on explicit reselect/override/use-X-this-time/clear-default or when no valid target decision exists.
|
|
7
|
+
Do not default to inline just because this state is inline or the helper is unavailable. Dispatch subagents only when the valid route decision selected subagent; otherwise execute inline in the main session.
|
|
6
8
|
After `trellis-check` / `trellis-check-all`, stop and report; point the user to Phase 3.4 `trellis-push` (or commit-only when needed). Do not run `/trellis:finish-work` unless the user explicitly asks after Phase 3.4 is complete.
|
|
7
9
|
This guard overrides any lower `Flow: ... -> /trellis:finish-work` line in this state block.
|
|
8
10
|
At Phase 3.4, code commit/push still goes through `trellis-push` (commit-only for commit-without-push); never bare `git commit`/`git push` on code (hub: Code Commit Confirmation Gate).
|
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
<!-- BEGIN skill-garden workflow-state in_progress v0.6 -->
|
|
2
2
|
HIGHEST PRIORITY SKILL-GARDEN STATE GUARD (in_progress):
|
|
3
|
-
|
|
4
|
-
Phase 2.2
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
If the helper is unavailable, ask numbered route choices and wait
|
|
3
|
+
This state block is a breadcrumb; the top-level skill-garden hub is the source of truth for route details.
|
|
4
|
+
At Phase 2.1/2.2, use the valid current-task `route_decision` for the target when it exists; otherwise run `trellis-route(implement|check)` or ask the numbered fallback choices and wait.
|
|
5
|
+
A valid route decision must come from `trellis-route`, `numbered-fallback`, or `route-prefs` read by `trellis-route`; prose, compact/SessionStart summaries, `codex-mode`, empty prefs, and old single-value prefs are not enough.
|
|
6
|
+
Reuse the valid current-task route through later implementation, repair, recheck, and final re-check; reroute only on explicit reselect/override/use-X-this-time/clear-default or when no valid target decision exists.
|
|
7
|
+
Do not spawn `trellis-implement` or `trellis-check*` unless the valid route decision selected subagent. If the helper is unavailable, do not default to inline; ask the numbered route choices and wait.
|
|
8
8
|
After `trellis-check` / `trellis-check-all`, stop and report; point the user to Phase 3.4 `trellis-push` (or commit-only when needed). Do not run `/trellis:finish-work` unless the user explicitly asks after Phase 3.4 is complete.
|
|
9
9
|
This guard overrides any lower `Flow: ... -> /trellis:finish-work` line in this state block.
|
|
10
10
|
At Phase 3.4, code commit/push goes through `trellis-push` (commit-only mode for commit-without-push); never bare `git commit`/`git push` on code (hub: Code Commit Confirmation Gate).
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
<!-- BEGIN skill-garden workflow-state no_task v0.6 -->
|
|
2
2
|
HIGHEST PRIORITY SKILL-GARDEN STATE GUARD (no_task):
|
|
3
|
-
Creating
|
|
4
|
-
After PRD ready and task started, next implementation action
|
|
5
|
-
If no active task exists, scan `.trellis/tasks/*/task.json` once per session for in-progress tasks with `last_push_snapshot`; surface completed_steps + next_step and suggest rebinding the active task before resuming.
|
|
6
|
-
Do NOT
|
|
7
|
-
If the turn is a meta edit to Trellis itself
|
|
3
|
+
Creating or resuming a task is not implementation permission.
|
|
4
|
+
After PRD is ready and the task is started, the next implementation action is Phase 2.1 `trellis-route(implement)` unless a valid current-task implement route decision already exists.
|
|
5
|
+
If no active task exists, scan `.trellis/tasks/*/task.json` once per session for in-progress tasks with `last_push_snapshot`; surface `completed_steps` + `next_step` and suggest rebinding the active task before resuming.
|
|
6
|
+
Do NOT call the harness built-in plan mode (`EnterPlanMode` / `ExitPlanMode`) for Trellis planning. It is not a substitute for Trellis task-creation consent, Trellis planning, or the route gate. For complex work, classify the turn, ask for task-creation consent, then use `trellis-brainstorm`.
|
|
7
|
+
If the turn is a meta edit to Trellis itself and Trellis tracking would be overkill, say so and ask to skip Trellis; never silently swap built-in plan mode in for the consent gate.
|
|
8
8
|
<!-- END skill-garden workflow-state no_task v0.6 -->
|
|
@@ -6,38 +6,37 @@
|
|
|
6
6
|
|
|
7
7
|
**Priority**: This hub overrides any conflicting Trellis workflow, skill, or command text for the scoped behaviors below.
|
|
8
8
|
|
|
9
|
-
**Scope**: Phase 2.1 implement routing, Phase 2.2 check/check-all routing,
|
|
9
|
+
**Scope**: Phase 2.1 implement routing, Phase 2.2 check/check-all routing, current-task route reuse, post-check stop, Phase 3.4 trellis-push, explicit Phase 3.5 finish-work bookkeeping, and push-progress recovery. State blocks should keep one short skill-garden sentinel; long-form rules live here.
|
|
10
10
|
|
|
11
11
|
**Mechanical rule**: use this hub as the source of truth. Do not add separate top-level skill-garden override sections or multiple skill-garden sentinels inside the same `workflow-state:*` block.
|
|
12
12
|
|
|
13
13
|
#### Routing Gate
|
|
14
14
|
|
|
15
|
-
|
|
15
|
+
A route decision is valid only when it is a current-task decision for the requested target (`implement` or `check`) and its structured `route_decision.source` is one of: `trellis-route`, `numbered-fallback`, or `route-prefs`.
|
|
16
16
|
|
|
17
|
-
Phase 2.
|
|
17
|
+
`route-prefs` is valid only when read by `trellis-route` after the workflow has already reached Phase 2.1 or Phase 2.2. The gitignored personal preference file `.trellis/.route-prefs.tmp` is developer-local execution-mode state; it must never be staged or committed, and it is never authorization to start work.
|
|
18
18
|
|
|
19
|
-
|
|
19
|
+
Before Phase 2.1 implement or Phase 2.2 check/check-all execution, use this order:
|
|
20
20
|
|
|
21
|
-
|
|
21
|
+
1. Reuse the valid current-task route decision for the requested target when one exists.
|
|
22
|
+
2. If the user explicitly asks to reselect, override, use another mode this time, or clear the default, ignore stored preferences for this decision and rerun `trellis-route` / the numbered fallback.
|
|
23
|
+
3. If no valid current-task decision exists for the target, run `trellis-route(target=implement|check)`. If the helper cannot ask through `AskUserQuestion` / `request_user_input`, ask the same numbered choices in normal chat and wait.
|
|
22
24
|
|
|
23
|
-
|
|
25
|
+
These are not valid route decisions by themselves: user prose such as "inline" or "I choose inline"; compact summaries; SessionStart summaries; `codex-mode`; empty `.trellis/.route-prefs.tmp`; old single-value prefs; and any remembered or summarized prior choice that does not carry a valid structured `route_decision`.
|
|
24
26
|
|
|
25
|
-
|
|
27
|
+
When a valid current-task implement/check decision exists, reuse it for later implementation in the same task, check failures, user-reported issues in the just-checked work, repair, recheck, and final re-check. Do not rerun `trellis-route` merely because check failed, code was repaired, or a final re-check is needed.
|
|
26
28
|
|
|
27
|
-
|
|
29
|
+
Phase 2.2 is the normal check execution point. Normal check routing returns only `trellis-check-all` paths: check-all inline or check-all subagent. Lightweight `trellis-check` is a hidden escape hatch only when the user explicitly asks for `light check` / `轻量检查`; it is not shown in normal check options.
|
|
28
30
|
|
|
29
|
-
|
|
31
|
+
`trellis-route` returns 2 normal modes for `target=implement` (inline/subagent) and 2 normal modes for `target=check` (check-all inline/check-all subagent).
|
|
32
|
+
Dispatch `trellis-implement`, `trellis-check`, or `trellis-check-all` only when the valid route decision selected subagent. If the valid route decision selected inline, execute inline in the main session.
|
|
30
33
|
|
|
31
34
|
Before invoking the skill, never:
|
|
32
35
|
- write pre-questions ("ready to start? / shall I proceed?")
|
|
33
36
|
- state "I lean towards X" or preview the inline/subagent options
|
|
34
37
|
- surface route options ahead of time
|
|
35
38
|
|
|
36
|
-
At
|
|
37
|
-
|
|
38
|
-
If the user says "temporary override", "reselect", "use X this time", "clear route default", or equivalent, the personal preference file must not take priority. `trellis-route` must show the override options again and let the user choose whether the choice is one-time, saved as the new default, or clears the default.
|
|
39
|
-
|
|
40
|
-
For normal check routing, default to `trellis-check-all` paths. Do not route to lightweight `trellis-check` unless the user explicitly asks for the hidden light-check escape hatch.
|
|
39
|
+
At Phase 2.1/2.2 boundaries, do not ask meta continuation questions. Either reuse the valid current-task route decision for the target, or obtain a new valid decision through `trellis-route` / numbered fallback.
|
|
41
40
|
|
|
42
41
|
#### Post-Check Stop Gate
|
|
43
42
|
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
|
-
"syncedAt": "2026-06-
|
|
2
|
+
"syncedAt": "2026-06-25T16:01:21.350Z",
|
|
3
3
|
"syncedFrom": "vendor/skill-garden/.trellis",
|
|
4
|
-
"sourceCommit": "
|
|
4
|
+
"sourceCommit": "97cb5d7e8bfda2c6504790e10cc2bf08e2f2d8fb",
|
|
5
5
|
"variants": {
|
|
6
6
|
"old": {
|
|
7
7
|
"claudeSkills": [],
|