@xulthekl/team-flow 0.43.1 → 0.44.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@xulthekl/team-flow",
-  "version": "0.43.1",
-  "description": "Unified plugin (24 skills + 15 agents) integrating team-flow, compound-engineering, architecture-design, prototype, design-system, workflow-orchestrator, workflow-bootstrap, e2e, session-handoff, workflow-feedback for multi-agent coding tools.",
+  "version": "0.44.0",
+  "description": "Unified plugin (25 skills + 16 agents) integrating team-flow, compound-engineering, architecture-design, prototype, design-system, workflow-orchestrator, workflow-bootstrap, e2e, session-handoff, workflow-feedback, business-analysis for multi-agent coding tools.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
   "bin": {

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "team-flow",
-  "version": "0.43.1",
-  "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking). 24 skills + 15 agents, one install.",
+  "version": "0.44.0",
+  "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking) + business-analysis (independent requirement/scenario artifact). 25 skills + 16 agents, one install.",
   "author": {
     "name": "LT"
   },

package/skills/business-analysis/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: business-analysis
+description: "独立业务分析 skill：将任意用户输入整理为结构化 requirement/vN/business-analysis.md，产出 Requirements List 与 Scenario List，支持多轮单问澄清、待办记录、新增/更新模式，写入前必须阻塞用户确认。不写入 ledger.md，不替代 workflow-orchestrator/ce-brainstorm。"
+argument-hint: "[需求/会议/文档描述] [vN 可选]"
+---
+
+# Business Analysis
+
+把任意输入（一句话、文档、会议纪要）整理成 `requirement/vN/business-analysis.md`，只含需求列表与业务场景列表两大板块。
+
+## Primary Goal
+
+- 提取并结构化需求（REQ-xxx）与业务场景（SC-xxx）
+- 通过多轮单问澄清补全缺失维度
+- 用户无法回答的问题记录为 TODO
+- 最终经用户阻塞确认后落盘
+
+## Inputs
+
+| 参数 | 说明 |
+|---|---|
+| `user_input` | 用户原始输入 |
+| `version` | 目标版本，如 `v1`；未提供时自动解析 |
+
+## Mode
+
+- **Create**：`requirement/vN/business-analysis.md` 不存在时新建
+- **Update**：已存在时读取现有条目，追加或修订
+
+## Process
+
+### 1. Resolve Version
+
+按 `references/version-resolution.md` 解析目标 `vN`，判断 Create / Update 模式。若文件已存在，询问用户「继续完善 / 新建版本 / 覆盖」。
+
+### 2. First-Pass Extraction
+
+从 `user_input` 中提取候选 REQ 与 SC，识别缺失维度。先以 🔵 pending 状态写入内部草案。
+
+### 3. One Question at a Time
+
+每次只问 1 个问题，优先选择题，其次开放题。问题应针对当前最大缺失：角色、目标、触发条件、前置条件、约束、可测试验收标准。
+
+### 4. TODO Handling
+
+用户答不上来时，立即在 `## Open Questions / TODOs` 段落记录 `TODO-xxx`，状态 `pending`。相关 REQ/SC 保持 🔵 pending。
+
+### 5. QA Check
+
+每轮更新后运行 `references/qa-checklist.md` 的 5 项 Error 检查。未通过则继续提问，最多 3 轮自修正。
+
+### 6. Final Confirmation
+
+展示完整文档预览，用户选择：
+- **Confirm**：写入文件，所有 🔵 翻转为 ✅ confirmed
+- **Adjust**：返回对话循环
+- **Abort**：保持 pending，不写入最终确认
+
+## Output Contract
+
+只写 `requirement/vN/business-analysis.md`。输出格式见 `references/output-schema.md`。
+
+严格禁止：
+- 写入 `ledger.md`
+- 写入 PRD、流程、架构等下游制品
+- 修改 `.team-flow.yaml`
+
+## Anti-Patterns
+
+- 一次问多个问题
+- 使用泛化角色如 "user"
+- Acceptance 写成不可测试的模糊描述
+- 未确认直接落盘
+
+## References
+
+- `references/output-schema.md` — 输出文档格式
+- `references/qa-checklist.md` — QA 检查标准
+- `references/interaction-rules.md` — 多轮交互与确认规则
+- `references/version-resolution.md` — 版本解析规则

package/skills/business-analysis/references/interaction-rules.md

@@ -0,0 +1,86 @@
+# 业务分析多轮交互规则
+
+本规则约束业务分析 skill 与用户的对话方式、待办处理、确认机制和断点恢复。
+
+## 核心交互原则
+
+### 一次只问一个问题
+
+- 每轮只向用户提出 **1 个** 清晰问题
+- 等待用户回答后再决定下一个问题
+- 禁止一次抛出 2 个及以上问题
+
+### 优先选择题
+
+- 当答案有限时，给出 2–3 个选项并推荐其一
+- 选项后简述每个选项的 trade-off
+- 用户可自由选择或给出新答案
+
+### 开放题仅用于真正开放的场景
+
+- 以下情况使用开放题：
+  - 用户首次输入极短，需要补充背景
+  - 询问 Acceptance 的具体阈值
+  - 确认业务角色名称
+
+## 待办（TODO）处理规则
+
+### 何时记录 TODO
+
+- 用户明确表示 "不知道"、"需要确认"、"后续补充"
+- 问题虽然重要，但当前无法获得可靠答案
+- 继续追问会影响对话收敛效率
+
+### 如何记录 TODO
+
+1. 在 `## Open Questions / TODOs` 段落新增一行：
+   - `TODO-xxx`
+   - 问题原文
+   - 记录日期
+   - 状态 `pending`
+   - 关联的 `REQ-xxx` / `SC-xxx`（如有）
+2. 将相关 REQ/SC 的状态保持为 🔵 pending
+3. 向用户复述已记录的 TODO，确认无误后继续
+
+### TODO 后续回填
+
+- 用户补充答案后，将 TODO 状态改为 `answered`
+- 把答案回填到对应 REQ/SC 的缺失维度
+- 重新运行 QA 检查
+
+## 确认机制
+
+### 增量确认（默认）
+
+- 每轮提取的结构化内容先以 🔵 pending 写入 `business-analysis.md`
+- 最终确认时统一把所有 🔵 翻转为 ✅ confirmed
+- 最终确认前展示完整文档预览，让用户选择 **Confirm / Adjust / Abort**
+
+### 最终确认内容
+
+确认前必须展示：
+- 当前 Requirements List 完整表格
+- 当前 Scenario List 完整表格
+- Open Questions / TODOs 列表
+- 本轮回新增/修改的摘要
+
+### 用户选择
+
+- **Confirm**：写入文件，pending → confirmed
+- **Adjust**：指出需要调整的条目，返回对话循环
+- **Abort**：保持当前 pending 状态，不翻转 confirmed，向用户说明已保存的 pending 内容
+
+## 终止条件
+
+正常终止需满足：
+- QA 所有 Error 检查通过，或
+- 用户明确说 "生成文档" / "确认输出"
+
+安全兜底：
+- 单轮对话最多 10 个问题；达到上限时强制进入最终确认
+
+## 断点恢复
+
+- `business-analysis.md` 本身就是断点载体
+- 恢复时先读取现有文件，把 ✅ confirmed 条目作为基线，🔵 pending 条目作为待确认内容
+- 向用户展示当前进度并询问 "继续完善 / 新建版本 / 覆盖"

package/skills/business-analysis/references/output-schema.md

@@ -0,0 +1,88 @@
+# business-analysis.md 输出格式
+
+本文件定义 `requirement/vN/business-analysis.md` 的精确格式。业务分析 skill 只能输出此格式，不得写入 `ledger.md`、PRD、流程或架构等下游制品。
+
+## 文件定位
+
+- 路径：`requirement/vN/business-analysis.md`
+- 作用：承接对话沉淀，为 PRD 提供需求与场景数据
+- 不直接写入 `requirement/ledger.md`；版本归档由 orchestrator 统一处理
+
+## Frontmatter
+
+```yaml
+---
+version: vN
+status: draft | confirmed
+last_updated: YYYY-MM-DD
+source: business-analysis skill
+---
+```
+
+## 必须包含的两大板块
+
+1. **需求列表（Requirements List）**
+2. **业务场景列表（Scenario List）**
+
+可选追加板块：
+
+3. **Open Questions / TODOs** —— 仅用于记录用户暂时无法回答的问题
+
+## 需求列表格式
+
+每个需求一行，字段如下：
+
+| 字段 | 要求 |
+|------|------|
+| ID | `REQ-xxx`，版本内顺序编号 |
+| Description | 一句话意图，用 SHALL/MUST 表达 |
+| Related Scenarios | `SC-xxx` 列表，逗号分隔 |
+| Status | 🔵 pending / ✅ confirmed |
+| Change History | `[vN.M YYYY-MM-DD create/modify 摘要]` |
+
+## 业务场景格式
+
+每个场景一行，字段如下：
+
+| 字段 | 要求 |
+|------|------|
+| ID | `SC-xxx` |
+| Role | 具体角色，禁止泛化 "user" |
+| Goal | 角色目标 |
+| Trigger | 触发事件/条件 |
+| Precondition | 前置条件 |
+| Constraint | 规则/限制/策略 |
+| Acceptance | 可测试成功条件，必须含具体阈值/字段/结果 |
+| Related Requirements | `REQ-xxx` 列表 |
+| Status | 🔵 pending / ✅ confirmed |
+| Change History | `[vN.M YYYY-MM-DD create/modify 摘要]` |
+
+## Open Questions / TODOs 格式
+
+| 字段 | 要求 |
+|------|------|
+| ID | `TODO-xxx` |
+| Question | 未能回答的问题原文 |
+| Recorded At | YYYY-MM-DD |
+| Status | pending / answered / dropped |
+| Related REQ/SC | 可选 |
+
+## 状态管理
+
+- 仅两种状态：🔵 pending、✅ confirmed
+- 状态转换只能经由用户阻塞确认
+- 确认前必须先通过 QA 检查
+
+## 与 PRD 的映射
+
+| PRD 章节 | 来源内容 |
+|---------|---------|
+| §7 D7.5_系统功能清单 | 需求列表 + 场景关联（REQ / SC） |
+| §8 D7.6_系统功能处理说明书 | 按场景分组的功能模块 |
+
+## 禁止事项
+
+- 禁止在 `business-analysis.md` 中直接写入 `ledger.md`
+- 禁止用泛化角色如 "user" 替代具体业务角色
+- 禁止 Acceptance 写成不可测试的模糊描述
+- 禁止写入业务流程详情（L1-L4、Mermaid、活动表等）

package/skills/business-analysis/references/qa-checklist.md

@@ -0,0 +1,31 @@
+# 业务分析 QA 检查清单
+
+业务分析 skill 在最终确认前必须执行以下 QA 检查。所有 Error 级别项必须全部通过，否则不得将条目标记为 ✅ confirmed。
+
+## Error 级别检查
+
+- [ ] **C1 角色覆盖**：用户输入中提到的所有具体角色都有对应的场景（SC-xxx）覆盖
+- [ ] **C2 六维度齐全**：每个场景都填满 Role / Goal / Trigger / Precondition / Constraint / Acceptance
+- [ ] **C3 REQ 引用存在**：场景中引用的 `REQ-xxx` 必须出现在需求列表中
+- [ ] **C4 对话证据可追溯**：每个场景都能在对话记录或输入中找到证据，禁止编造
+- [ ] **C5 Acceptance 可测试**：验收标准必须具体、可验证，含明确阈值/字段/结果
+
+## Warning 级别检查
+
+- [ ] **W1 角色具体化**：不存在 "user"、"管理员" 等泛化角色，除非已明确定义为业务角色
+- [ ] **W2 需求表述**：需求描述使用 SHALL/MUST，避免 "should"、"可以" 等弱约束
+- [ ] **W3 变更历史**：新增或修改的条目都含变更历史
+
+## QA 不通过时的处理
+
+1. 定位导致失败的条目和维度
+2. 向用户提出**一个**针对性的澄清问题
+3. 根据回答更新文档
+4. 重新运行 QA 检查
+5. 最多允许 3 轮内部自修正；仍无法通过则记录 TODO 并保持 pending
+
+## 待办（TODO）的 QA 规则
+
+- TODO 问题可以暂时不阻塞其他已确认条目的确认
+- 与 TODO 相关的 REQ/SC 必须保持 🔵 pending 状态
+- 用户后续补充答案后，应更新 TODO 状态为 answered 并回填到对应条目

package/skills/business-analysis/references/version-resolution.md

@@ -0,0 +1,41 @@
+# 业务分析版本解析规则
+
+本规则定义业务分析 skill 如何确定目标版本 `vN`。
+
+## 解析顺序
+
+按以下优先级依次解析：
+
+1. **显式参数**：用户在调用 skill 时传入的版本，如 `business-analysis v2`
+2. **运行时配置**：`tf runtime config --get active.requirement`（若返回有效值）
+3. **目录扫描**：读取 `requirement/` 下已有的 `vN` 目录，取最大 N
+4. **默认回退**：以上皆无时使用 `v1`
+
+## 目录扫描规则
+
+- 只识别 `requirement/vN/` 形式目录，其中 N 为正整数
+- 忽略非版本目录（如 `archived/`、`draft/`）
+- 若存在 `v1`、`v2`、`v3`，则取 `v3`
+
+## 模式判断
+
+解析出版本后，判断当前是 Create 还是 Update 模式：
+
+| 条件 | 模式 | 行为 |
+|---|---|---|
+| `requirement/vN/business-analysis.md` 不存在 | Create | 新建文件 |
+| 文件已存在 | Update | 读取现有条目，追加或修订 |
+
+## 已存在文件的处理
+
+检测到文件已存在时，必须向用户询问以下三者之一：
+
+- **继续完善**：在当前版本基础上追加/修改条目
+- **新建版本**：创建 `v(N+1)/business-analysis.md`，旧版本保持 archived
+- **覆盖**：清空当前版本重新生成（不推荐，需用户明确确认）
+
+## 版本号输出
+
+- 最终输出的 `business-analysis.md` frontmatter 中必须包含 `version: vN`
+- Change History 中的版本号采用 `vN.M` 形式，其中 M 为本次编辑的次要版本（同一 vN 内递增）
+- 首次创建使用 `vN.1`，后续补充依次递增