flower-trellis 0.1.0

package/enhancements/old/.agents/skills/push/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: push
+description: "Push — 一键 commit → push → 可选 merge 到目标分支（测试线），支持多仓库，merge_target 记录在 config.yaml 中"
+---
+# Push — 提交并推送（可选合并到目标分支）
+
+一键完成 commit → push → 可选 merge 到目标分支（通常是测试线）→ push 目标分支 → 切回。
+
+支持多仓库（frontend / backend），merge 目标分支记录在 `.trellis/config.yaml` 的 `packages.<name>.merge_target` 中。
+
+---
+
+## 配置
+
+目标分支存储在 `.trellis/config.yaml` 的 packages 配置中：
+
+```yaml
+packages:
+  frontend:
+    path: iqs-front-human
+    git: true
+    merge_target: test      # 首次 push 时询问后自动写入
+  backend:
+    path: iqs
+    git: true
+    merge_target: test
+```
+
+> 首次运行时如果 `merge_target` 不存在，会在 merge 步骤询问目标分支并回写到 `config.yaml`。
+> 如需修改，直接编辑 `config.yaml` 或使用 `/trellis:push --reconfigure`。
+
+---
+
+## 执行步骤
+
+### Step 0: 读取配置
+
+读取 `.trellis/config.yaml` 中的 `packages` 配置，识别所有 `git: true` 的仓库及其 `merge_target`（如果已配置）。
+
+### Step 1: 检测变更
+
+读取 `.trellis/config.yaml` 中的 `packages` 配置，对每个 git 仓库检测变更：
+
+```bash
+# 对每个 package
+cd <package_path>
+git status --short
+```
+
+列出有变更的仓库。如果所有仓库都没有变更，提示用户并终止。
+
+如果只有部分仓库有变更，只处理有变更的仓库。
+
+### Step 2: 逐仓库处理
+
+对每个有变更的仓库，依次执行以下操作：
+
+#### 2.1 展示变更摘要
+
+```bash
+cd <package_path>
+git diff --stat
+git diff --name-only
+```
+
+#### 2.2 暂存文件
+
+展示要暂存的文件列表，**获得用户确认后**再暂存。
+
+```bash
+git add <具体文件列表>
+```
+
+> **[!] 禁止使用 `git add -A` 或 `git add .`**
+> 必须明确列出文件，避免误提交敏感文件（.env、credentials 等）。
+
+#### 2.3 生成 commit message 并提交
+
+分析变更内容，生成符合项目风格的 commit message：
+- 读取最近 5 条 commit 参考风格
+- 类型前缀：`feat` / `fix` / `chore` / `refactor` 等
+- 简短描述变更内容
+- 使用中文描述
+
+```bash
+git commit -m "<type>(<scope>): <description>"
+```
+
+#### 2.4 Push 当前分支
+
+```bash
+git push origin <current_branch>
+```
+
+如果远程没有该分支，使用 `-u` 建立跟踪：
+
+```bash
+git push -u origin <current_branch>
+```
+
+#### 2.5 询问是否 Merge 到目标分支（可选）
+
+Push 完成后，检查该 package 是否已配置 `merge_target`：
+
+**已配置 `merge_target`**：
+
+```markdown
+<package> 已推送到 <current_branch>。是否合并到 <merge_target>？
+
+1. 是，合并到 <merge_target>
+2. 否，跳过
+```
+
+**未配置 `merge_target`（首次）**：
+
+```markdown
+<package> 已推送到 <current_branch>。是否需要合并到其他分支（如测试线）？
+
+1. 是，请输入目标分支名
+2. 否，跳过
+```
+
+如果用户输入了目标分支名，**将其回写到 `.trellis/config.yaml`** 对应 package 的 `merge_target` 字段，下次自动使用。
+
+**如果用户选择合并**：
+
+```bash
+# 切换到目标分支并拉取最新
+git checkout <target_branch>
+git pull origin <target_branch>
+
+# 合并当前开发分支
+git merge <current_branch> --no-edit
+
+# Push 目标分支
+git push origin <target_branch>
+
+# 切回开发分支
+git checkout <current_branch>
+```
+
+> **[!] 如果 merge 出现冲突：**
+> 1. 立即停止，展示冲突文件列表
+> 2. 询问用户：手动解决 / 中止 merge
+> 3. **绝对不能** `git merge --abort` 后静默跳过
+
+**如果用户选择跳过**：直接进入下一个仓库或输出结果。
+
+### Step 3: 输出结果
+
+```markdown
+## Push 结果
+
+| 仓库 | 分支 | 目标 | commit | 状态 |
+|------|------|------|--------|------|
+| frontend | v1.3 | test | abc1234 feat(...): ... | ✅ 已合并 |
+| backend | v1.3 | test | def5678 fix(...): ... | ⏭️ 跳过合并 |
+
+所有变更已推送到目标分支。
+```
+
+---
+
+## 参数
+
+| 参数 | 说明 | 示例 |
+|------|------|------|
+| （无参数） | 自动检测所有有变更的仓库并处理 | `/trellis:push` |
+| `--only <package>` | 只处理指定仓库 | `/trellis:push --only frontend` |
+| `--reconfigure` | 重新配置目标分支 | `/trellis:push --reconfigure` |
+| `--target <branch>` | 临时指定目标分支（不修改配置） | `/trellis:push --target hotfix` |
+
+---
+
+## 安全机制
+
+1. **暂存确认** — 每个仓库暂存前展示文件列表，用户确认
+2. **commit message 确认** — 展示生成的 message，用户可修改
+3. **merge 冲突处理** — 冲突时暂停，不静默跳过
+4. **不碰主分支** — 如果目标分支是 `master` / `main`，额外警告确认
+5. **不使用 force push** — 始终使用普通 push
+
+---
+
+## 反模式（避免）
+
+- ❌ `git add -A`（可能误提交敏感文件）
+- ❌ merge 冲突后静默 abort（用户需要知道）
+- ❌ 未经确认直接 commit（必须让用户看到 message）
+- ❌ force push 到目标分支
+- ❌ 在目标分支上直接开发（只 merge，不在目标分支上改代码）

package/enhancements/old/.agents/skills/re-implement/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: re-implement
+description: "二次实现 - 需求变更后重新调用 Implement Agent"
+---
+# 二次实现 - 需求变更后重新调用 Implement Agent
+
+当任务实施过程中出现需求漂移或变动时，重新调用 Implement Agent 实现更新后的需求。
+
+---
+
+## 使用场景
+
+- 任务已通过 `/trellis:start` 完成了首次实现
+- 实施过程中需求发生了变更或补充
+- PRD 已更新，需要 Implement Agent 根据新需求重新实现
+- 用户在 check 或测试阶段发现需要调整方向
+
+---
+
+## 前置条件
+
+- 当前任务已激活（`.trellis/.current-task` 已设置）
+- 任务目录下存在 `prd.md`（已更新为最新需求）
+- 任务目录下存在 `implement.jsonl`（code-spec context 配置）
+
+---
+
+## 执行步骤
+
+### Step 1: 确认当前任务状态 `[AI]`
+
+```bash
+python3 ./.trellis/scripts/get_context.py
+```
+
+确认：
+- 当前任务存在且已激活
+- 任务目录路径
+
+如果没有激活的任务，提示用户先通过 `/trellis:start` 开始任务。
+
+### Step 2: 了解变更内容 `[AI]`
+
+读取当前 PRD 和已有代码变更，理解上下文：
+
+1. 读取 `prd.md` 了解当前需求
+2. 运行 `git diff --name-only` 了解已有代码变更
+3. 询问用户：需求哪里变了？
+
+### Step 3: 更新 PRD `[AI]`
+
+根据用户描述的变更，更新 `prd.md`：
+
+- 在 `## Requirements` 中标注新增/修改/删除的需求
+- 更新 `## Acceptance Criteria`
+- 在 `## Technical Notes` 中记录变更原因
+
+**格式建议**（在 PRD 中追加）：
+
+```markdown
+## 变更记录
+
+### 变更 1: <变更标题> (YYYY-MM-DD)
+- **原需求**: <原来是什么>
+- **新需求**: <现在要什么>
+- **原因**: <为什么要改>
+- **影响范围**: <哪些已实现的代码需要调整>
+```
+
+### Step 4: 评估是否需要更新 Context 配置 `[AI]`
+
+判断变更是否涉及新的模块或规范：
+
+- 如果**不涉及新模块**：直接进入 Step 5
+- 如果**涉及新模块**：先补充 context 配置
+
+```bash
+# 需要时追加 code-spec context
+python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "<新路径>" "<原因>"
+python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "<新路径>" "<原因>"
+```
+
+### Step 5: 调用 Implement Agent `[AI]`
+
+调用 Implement Agent 执行二次实现（code-spec context 由 hook 自动注入）：
+
+```
+Agent(
+  subagent_type: "implement",
+  prompt: "基于更新后的 prd.md 重新实现任务。
+
+  注意：这是一次需求变更后的二次实现。
+  - 阅读 prd.md 中的「变更记录」章节，理解哪些需求发生了变化
+  - 保留已有的正确实现，只修改需要调整的部分
+  - 如果变更涉及已实现的逻辑，确保修改后不破坏原有功能
+  - 遵循所有已注入的 code-spec 规范
+  - 完成后报告修改/新增的文件列表",
+  model: "opus"
+)
+```
+
+### Step 6: 调用 Check Agent `[AI]`
+
+实现完成后，调用 Check Agent 验证（code-spec context 由 hook 自动注入）：
+
+```
+Agent(
+  subagent_type: "check",
+  prompt: "检查所有代码变更是否符合 code-spec 规范。
+
+  重点关注：
+  - 二次实现是否正确反映了 prd.md 中的变更需求
+  - 新旧代码之间是否存在不一致
+  - 修改是否引入了回归问题
+  - 直接修复发现的问题
+  - 确保 lint 和 typecheck 通过",
+  model: "opus"
+)
+```
+
+### Step 7: 报告结果 `[AI]`
+
+输出二次实现的结果摘要：
+
+```markdown
+## 二次实现完成
+
+### 需求变更
+- <变更点 1>
+- <变更点 2>
+
+### 代码变更
+- <修改的文件 1>: <做了什么>
+- <修改的文件 2>: <做了什么>
+
+### 验证状态
+- [ ] Lint 通过
+- [ ] Typecheck 通过
+- [ ] Check Agent 验证通过
+
+### 下一步
+- 测试变更
+- 确认无误后提交
+- 运行 `/trellis:finish-work` 检查清单
+```
+
+---
+
+## 与其他命令的关系
+
+| 命令 | 阶段 | 说明 |
+|------|------|------|
+| `/trellis:start` | 首次实现 | 完整流程：Research → Context → Implement → Check |
+| `/trellis:re-implement` | 二次实现 | 需求变更后：更新 PRD → Implement → Check |
+| `/trellis:finish-work` | 完成 | 提交前检查清单 |
+
+---
+
+## 核心原则
+
+| 原则 | 说明 |
+|------|------|
+| **增量修改** | 保留正确的已有实现，只改变需要调整的部分 |
+| **PRD 先行** | 先更新 PRD 再调 Implement Agent，确保上下文准确 |
+| **Context 自动注入** | implement.jsonl + prd.md 由 hook 自动注入，无需手动传递 |
+| **记录变更原因** | 在 PRD 变更记录中说明为什么改、改了什么 |

package/enhancements/old/.agents/skills/sync-prd/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: sync-prd
+description: "同步 PRD - 代码/需求变更后回补 PRD"
+---
+# 同步 PRD - 代码/需求变更后回补 PRD
+
+当你直接修改了任务相关的代码或需求，但没有同步更新任务的 `prd.md` 时，使用此命令将 PRD 与实际变更对齐。
+
+**时机**：代码或需求已变更，但 PRD 未同步更新
+
+---
+
+## 使用场景
+
+- 直接改了代码逻辑，但没更新 PRD 中的需求描述
+- 用户口头调整了需求，代码已改但 PRD 仍是旧版本
+- Code Review 后修改了实现方式，PRD 未反映
+- 多次小修改累积后，PRD 与实际实现已出现偏差
+- 任务完成前的最终检查，确认 PRD 是文档真实来源
+
+---
+
+## 执行步骤
+
+### Step 1: 确认当前任务 `[AI]`
+
+```bash
+python3 ./.trellis/scripts/get_context.py
+```
+
+确认：
+- 当前有激活的任务（`.trellis/.current-task` 已设置）
+- 任务目录路径和 PRD 文件存在
+
+如果没有激活的任务，询问用户要同步哪个任务的 PRD。
+
+### Step 2: 读取现有 PRD `[AI]`
+
+读取任务目录下的 `prd.md`，理解当前文档化的需求。
+
+### Step 3: 收集实际变更 `[AI]`
+
+从多个来源收集实际变更信息：
+
+**3a. 代码变更**（如有）：
+```bash
+# 查看当前未提交的变更
+cd srm-boot && git diff --name-only && git diff --cached --name-only
+# 查看最近与任务相关的提交
+cd srm-boot && git log --oneline -20
+```
+
+**3b. 用户描述**：
+- 询问用户："相比 PRD 中记录的内容，实际做了哪些不同的变更？"
+- 提供多选引导：
+  - 需求范围变了（增加/删减了功能点）
+  - 实现方式变了（技术方案调整）
+  - 接口/字段变了（API、数据库、DTO 等）
+  - 业务规则变了（校验逻辑、流程等）
+  - 其他
+
+### Step 4: 对比分析 `[AI]`
+
+将 PRD 内容与实际变更进行对比，识别差异：
+
+```markdown
+## PRD 偏差分析
+
+### 新增（PRD 中没有，但实际已实现）
+- <变更 1>
+
+### 删除（PRD 中有，但实际未实现或已移除）
+- <变更 2>
+
+### 修改（PRD 描述与实际实现不一致）
+- <变更 3>: PRD 说 X，实际是 Y
+```
+
+将分析结果展示给用户确认。
+
+### Step 5: 更新 PRD `[AI]`
+
+经用户确认后，更新 `prd.md`：
+
+1. **更新主体内容**：修改 Goal、Requirements、Acceptance Criteria 等章节，使其反映实际状态
+2. **追加变更记录**：在文末追加变更日志
+
+**变更记录格式**：
+
+```markdown
+## 变更记录
+
+### 变更 <N>: <简要描述> (YYYY-MM-DD)
+- **变更类型**: 需求变更 / 实现调整 / 范围变更
+- **变更内容**: <具体改了什么>
+- **原因**: <为什么改>
+- **PRD 同步方式**: 事后回补（代码先行）
+```
+
+### Step 6: 报告结果 `[AI]`
+
+```markdown
+## PRD 同步完成
+
+### 偏差摘要
+- 新增 <N> 项需求/实现
+- 删除 <N> 项需求/实现
+- 修改 <N> 项描述
+
+### 更新的章节
+- <章节 1>: <做了什么调整>
+- <章节 2>: <做了什么调整>
+
+### 下一步
+- 确认 PRD 内容准确
+- 如有后续开发，PRD 已可作为最新参考
+- 如任务已完成，可运行 `/trellis:finish-work`
+```
+
+---
+
+## 与其他命令的关系
+
+| 命令 | 阶段 | 说明 |
+|------|------|------|
+| `/trellis:brainstorm` | 需求梳理 | PRD 从零创建，边讨论边完善 |
+| `/trellis:re-implement` | 需求变更 | 先更新 PRD，再调 Implement Agent |
+| `/trellis:sync-prd` | 事后回补 | 代码已改，PRD 未同步，回补文档 |
+| `/trellis:finish-work` | 完成检查 | 提交前整体检查清单 |
+
+```
+典型流程：
+  PRD → 实现 → PRD 同步          # 理想流程（re-implement）
+  PRD → 实现 → 偏差 → sync-prd   # 补救流程（本命令）
+```
+
+---
+
+## 核心原则
+
+| 原则 | 说明 |
+|------|------|
+| **PRD 是真实来源** | PRD 应始终反映任务的最新状态，而非初始计划 |
+| **事后回补优于不补** | 即使是事后同步，也比让 PRD 过时不管要好 |
+| **记录变更原因** | 追加变更记录，让后续开发者理解演变过程 |
+| **用户确认为准** | 对比分析需经用户确认后再更新，避免错误同步 |

package/enhancements/old/.claude/commands/trellis/analyze-task.md

@@ -0,0 +1,139 @@
+# 任务深度分析与细化
+
+对 `.trellis/tasks/` 下的已有任务进行深入分析，提供全景预览、识别风险点，并通过交互式问答细化任务内容。
+
+---
+
+## 使用方式
+
+```
+/trellis:analyze-task [task-slug]
+```
+
+- 如果提供了 `task-slug`，直接分析该任务
+- 如果未提供，列出所有活跃任务让用户选择
+
+---
+
+## 执行步骤
+
+### Step 1: 定位任务
+
+```bash
+# 未指定任务时，列出所有活跃任务
+python3 ./.trellis/scripts/task.py list
+```
+
+- 如果用户未指定任务，展示任务列表并用 `AskUserQuestion` 让用户选择
+- 定位后，读取任务目录下的 `task.json` 和 `prd.md`（如果存在）
+
+### Step 2: 上下文收集（静默执行，不问用户）
+
+在分析之前，自动收集信息：
+
+1. **任务文件**：读取 `task.json`、`prd.md`（如果有）
+2. **相关代码**：如果任务涉及具体模块，快速扫描相关代码结构
+3. **依赖任务**：检查是否有关联或依赖的任务
+4. **历史记录**：检查 journal 中是否有该任务的相关记录
+
+### Step 3: 输出分析报告
+
+以下列结构输出分析报告：
+
+```markdown
+## 任务分析报告: <任务标题>
+
+### 概述
+<用 2-3 句话总结这个任务要做什么、为什么要做>
+
+### 工作预览
+预计需要做的事情：
+1. <步骤 1>
+2. <步骤 2>
+3. ...
+
+### 涉及范围
+- **模块/文件**: <涉及哪些模块或文件>
+- **影响面**: <这个变更会影响到什么>
+- **依赖**: <需要什么前置条件>
+
+### 风险点
+1. <风险 1>: <说明 + 可能的后果>
+2. <风险 2>: <说明 + 可能的后果>
+
+### 不明确的地方
+1. <问题 1>: <为什么这个需要澄清>
+2. <问题 2>: <为什么这个需要澄清>
+
+### 建议
+- <可选的改进建议或替代方案>
+```
+
+### Step 4: 交互式反问
+
+报告输出后，**逐个**向用户提出不明确的问题（每次只问一个）。
+
+使用 `AskUserQuestion` 工具提问，优先提供选项：
+
+```markdown
+关于 <问题主题>，你倾向于哪种方式？
+
+1. **选项 A** — <含义 + 利弊>
+2. **选项 B** — <含义 + 利弊>
+3. **其他** — 你来说明
+```
+
+### Step 5: 根据反馈更新任务
+
+每收到一个回答后：
+1. **立即更新** `prd.md`（如果存在）或创建新的 `prd.md`
+2. **更新** `task.json` 中的相关字段（如优先级、描述等）
+3. 继续下一个问题，直到所有不明确的地方都澄清
+
+### Step 6: 输出细化结果
+
+所有问题回答完毕后，输出最终的细化摘要：
+
+```markdown
+## 任务细化完成
+
+### 变更摘要
+- <列出 prd.md / task.json 的变更内容>
+
+### 下一步
+- 如果准备开发：运行 `/trellis:start` 进入开发流程
+- 如果需要进一步讨论：继续对话
+```
+
+---
+
+## 核心原则
+
+| 原则 | 说明 |
+|------|------|
+| **先分析后提问** | 先展示你的分析和理解，再提问 |
+| **每次只问一个问题** | 不要用问题列表轰炸用户 |
+| **提供选项** | 尽量给出可选方案而非开放式问题 |
+| **即时更新** | 每次收到回答立即更新文档 |
+| **识别真正的风险** | 区分「可能的风险」和「确定的风险」 |
+| **YAGNI** | 挑战不必要的复杂度，聚焦真正需要的 |
+
+---
+
+## 与其他命令的区别
+
+| 命令 | 用途 | 输入 |
+|------|------|------|
+| `/trellis:brainstorm` | 从模糊想法出发，发现需求 | 用户的初始想法 |
+| `/trellis:analyze-task` | 对已有任务深入分析和细化 | 已存在的 task |
+| `/trellis:start` | 开始开发流程 | 明确的任务 |
+
+---
+
+## 反模式（避免）
+
+- ❌ 直接输出一大堆问题让用户回答
+- ❌ 不看代码就做分析（先收集上下文）
+- ❌ 分析报告过于笼统（要具体到文件和模块）
+- ❌ 过度细化不重要的细节
+- ❌ 忽略跨模块影响