@deepstorm/cli 0.1.0

package/dist/skills/tide-discuss/references/data-format.md

@@ -0,0 +1,237 @@
+# 数据格式参考
+
+## 会话 ID 格式
+
+```
+tide-YYYYMMDD-NNN
+```
+
+- YYYYMMDD = 当前日期
+- NNN = 当日递增序列号（从 001 开始）
+- 例：`tide-20260611-001`
+
+**序列号维护：** `tide-data/sessions/.sequence` 文件记录上次序列号，格式为 `20260611 005`。首日没有此文件时从 001 开始。
+
+**跨天处理：** 读取 `.sequence` 文件时，检查日期部分是否等于今天。如果日期不等于今天（跨天了），将 NNN 重置为 `001` 并从 `001` 开始。
+
+**异常处理：** 如果 `.sequence` 文件内容损坏（格式错误、日期乱码等），**忽略该文件，重新生成**。基于当前 `sessions/` 目录中最大的 sessionId 序列号 + 1 计算新序列号。如果 `sessions/` 为空，从 001 开始。
+
+---
+
+## Feature ID 格式
+
+```
+MODULE-FUNCTION-SUBFUNCTION
+```
+
+全大写 + 连字符，例：`AUTH-LOGIN-WECOM`、`PAYMENT-ORDER-REFUND`。
+
+**自动生成规则（当用户未指定时）：**
+1. 先将需求描述**翻译成英文**，准确表达原意
+2. 从英文翻译中提取 2-4 个核心关键词，按逻辑层级排列：`模块-功能-子功能`
+3. 如果需求跨多个领域，取最核心的意图
+
+> 例如：用户说"添加企业微信扫码登录" → 翻译为 "Add WeChat Work QR code login" → 提取 `AUTH-LOGIN-WECOM`
+> 用户说"优化商品列表的加载速度" → 翻译为 "Optimize product list loading speed" → 提取 `PRODUCT-LOAD-OPTIMIZE`
+
+**长度限制：** featureId 不超过 **5 个英文单词**（`AUTH-LOGIN-WECOM` 计为 3 个，`PAYMENT-ORDER-REFUND-V2` 计为 4 个）。
+
+**备选机制：** 如果 AI 对提取哪 2-4 个词拿不准，提供 **2-3 个备选方案**让用户选择，不要自己做主。
+
+**原则：** 生成的 featureId 要能让人一眼看出需求意图，不要用无意义的 hash 或过短的缩写。
+
+---
+
+## Session JSON 格式
+
+```json
+{
+  "sessionId": "tide-20260611-001",
+  "featureId": "AUTH-LOGIN-WECOM",
+  "brief": "企业微信扫码登录",
+  "createdAt": "2026-06-11T10:00:00.000Z",
+  "status": "completed",
+  "parent": null,
+  "supersededBy": null,
+  "services": {
+    "knowledgeBase": {
+      "provider": "feishu-wiki",
+      "url": "https://feishu.cn/wiki/xxx"
+    },
+    "issueTracker": {
+      "provider": "jira",
+      "urls": [
+        "https://jira.example.com/browse/PROJ-123",
+        "https://jira.example.com/browse/PROJ-124"
+      ],
+      "taskBreakdown": [
+        {"title": "支持企业微信扫码登录", "fr": "FR-1", "priority": "P0",
+         "acceptance": ["用户可通过企业微信扫码完成登录"],
+         "description": "实现企业微信 OAuth 扫码登录流程"},
+        {"title": "扫码授权页 UI", "fr": "FR-2", "priority": "P1",
+         "acceptance": ["页面在移动端和 PC 端均正常显示"],
+         "description": "设计扫码授权页面，包含二维码展示和状态提示"}
+      ]
+    }
+  },
+  "dingtalkUrl": "https://feishu.cn/wiki/xxx",  // 向后兼容旧字段，新 session 使用 services.knowledgeBase
+  "jiraUrls": [
+    "https://jira.example.com/browse/PROJ-123",
+    "https://jira.example.com/browse/PROJ-124"
+  ],
+  "jiraTaskBreakdown": [
+    {"title": "支持企业微信扫码登录", "fr": "FR-1", "priority": "P0",
+     "acceptance": ["用户可通过企业微信扫码完成登录"],
+     "description": "实现企业微信 OAuth 扫码登录流程"}
+  ],
+  "publishChecklist": [
+    {"step": "knowledge_base_push", "done": true, "note": "已推送到知识库"},
+    {"step": "issue_task_split", "done": true, "note": "用户已确认 2 个任务"},
+    {"step": "create_issues", "done": true, "total": 2, "created": 2}
+  ],
+  "steps": [
+    {
+      "role": "analyst",
+      "summary": "讨论了企业微信在企业通讯录...",
+      "decisions": ["使用扫码而非手动输入"],
+      "requirements": ["支持企业微信扫码"],
+      "skipped": false,
+      "checklist": [
+        {"item": "需求背景和业务目标", "done": true},
+        {"item": "目标用户画像", "done": true},
+        {"item": "核心痛点分析", "done": true},
+        {"item": "竞品和市场调研", "done": true},
+        {"item": "关键成功指标", "done": true}
+      ],
+      "completedAt": "2026-06-11T10:15:00.000Z"
+    }
+  ]
+}
+```
+
+### 字段说明 — services 命名空间（新字段）
+
+|字段|类型|说明|
+|---|---|---|
+|`services.knowledgeBase`|object \| null|知识库服务信息。4a 成功后写入，含 `provider`（MCP 服务 ID）和 `url`（文档链接）|
+|`services.issueTracker`|object \| null|工单系统信息。4b+4c 过程中写入，含 `provider`、`urls` 数组（自动去重）、`taskBreakdown`（任务清单）|
+
+### 字段说明 — 通用字段
+
+|字段|类型|说明|
+|---|---|---|
+|`sessionId`|string|会话唯一 ID，格式 `tide-YYYYMMDD-NNN`|
+|`featureId`|string|功能标识，格式 `MODULE-FUNCTION-SUBFUNCTION`|
+|`brief`|string|需求中文概要，AI 从用户输入提炼，**不超过 50 字**。用于列表展示和关键词搜索匹配|
+|`createdAt`|string (ISO 8601)|会话创建时间|
+|`status`|string|会话状态，见下方状态说明|
+|`parent`|string \| null|需求变更/重来时关联的旧会话 sessionId；`null` 表示原始会话|
+|`supersededBy`|string \| null|取代此会话的新会话 sessionId；`null` 表示未被取代|
+|`steps`|array|角色讨论记录数组，每个 step 包含：`role`, `summary`, `decisions`, `requirements`, `skipped`, `checklist`, `completedAt`|
+|`publishChecklist`|array|发布流程 checklist，每项含 `{step, done, note?, skipped?, total?, created?, failedItems?}`。`failedItems` 记录失败的具体条目明细，标准格式见下方。步骤名：`knowledge_base_push` / `issue_task_split` / `create_issues`|
+
+### 向后兼容旧字段
+
+以下旧字段保留为向后兼容别名。新代码优先使用 `services` 命名空间，读取时降级：
+
+|旧字段|新字段|降级规则|
+|---|---|---|
+|`dingtalkUrl`|`services.knowledgeBase.url`|`services.knowledgeBase` 不存在时读取 `dingtalkUrl`|
+|`jiraUrls`|`services.issueTracker.urls`|`services.issueTracker` 不存在时读取 `jiraUrls`|
+|`jiraTaskBreakdown`|`services.issueTracker.taskBreakdown`|`services.issueTracker.taskBreakdown` 不存在时读取 `jiraTaskBreakdown`|
+
+**读写规则：**
+- **写操作：** 统一写入 `services` 命名空间，不再写入旧字段
+- **读操作：** 优先读取 `services` 命名空间，不存在时降级到旧字段
+- **AI 展示：** 优先展示 `services` 中的值；展示给用户时使用通用名称（"知识库"、"工单"），而非特定服务名
+
+> **PRD JSON 快照说明：** `prds/{sessionId}-prd.json` 是 Step 3 生成 PRD 时的结构化快照。session JSON 后续会更新（如 `services`、`publishChecklist`），PRD JSON 不会再同步更新；如需最新状态，以 session JSON 为准。格式定义详见 `references/prd-template.md`。
+
+### Steps 子字段
+
+|字段|类型|说明|
+|---|---|---|
+|`role`|string|角色 ID：`analyst` / `pm` / `architect` / `designer` / `po`|
+|`summary`|string|本角色讨论总结|
+|`decisions`|string[]|关键决策列表|
+|`requirements`|string[]|功能需求/要求列表|
+|`skipped`|boolean|是否为用户跳过的可选角色，缺省 `false`|
+|`checklist`|array|讨论进度清单，每项含 `{item: string, done: boolean}`|
+|`completedAt`|string \| null|完成时间。有值 = 该角色已处理完毕（已完成**或**已跳过，配合 `skipped` 区分）；`null` = 尚未处理|
+
+### 状态说明
+
+|状态|含义|何时设置|后续操作|
+|---|---|---|---|
+|`active`|讨论进行中。还有角色未完成或可选角色待询问。|Step 1 新建时设为此值|继续角色讨论|
+|`prd_ready`|PRD 已生成。所有必需角色讨论完成，PRD 文件已写入磁盘。|Step 3 PRD 生成后设为此值|查看 PRD、推送到知识库（4a）、变更需求|
+|`published`|已发布到知识库。4a 执行成功或已跳过，等待 4b 任务拆分。|Step 4a 成功后（或跳过时）设为此值|查看 PRD、拆分为任务（4b）、变更需求|
+|`publish_error`|发布过程中出错。知识库推送或工单创建失败。|Step 4a 或 4c 执行失败时设为此值|查看 PRD、重试发布、放弃发布（→ superseded）|
+|`completed`|工单已创建（或全部跳过）。所有发布步骤完成，整个需求工作流完结。**自动归档到 `archive/` 目录。**|Step 4c 成功（或全部跳过）后设为此值|查看 PRD 和工单（只读归档）|
+|`superseded`|已废弃（变更需求/放弃/重来）。此需求已被取代、放弃或重来。**自动归档到 `archive/` 目录。**|用户选择「变更需求」「放弃」或「重来」时设为此值|查看历史和替代会话（只读归档）|
+
+### 状态流转图
+
+```mermaid
+flowchart TD
+    ACTIVE["active"] -->|"Step 3 自动触发"| PRD_READY["prd_ready"]
+    ACTIVE -->|"放弃 / 变更需求"| SUPERSEDED["superseded（已废弃）"]
+
+    PRD_READY -->|"变更需求/重来"| SUPERSEDED
+
+    PRD_READY --- PUB_WAIT["（发布阶段）"]
+    PUB_WAIT -->|"4a 推送到知识库"| PUBLISHED["published"]
+    PUB_WAIT -->|"4a 失败"| PUB_ERR["publish_error"]
+
+    PUBLISHED -->|"4b+4c 完成"| COMPLETED["completed（终态）"]
+    PUBLISHED -->|"变更需求"| SUPERSEDED
+    PUBLISHED -.->|"4c 部分失败"| PUB_ERR
+
+    PUB_ERR -->|"重试"| PUB_WAIT
+    PUB_ERR -->|"放弃发布"| SUPERSEDED
+
+    SUPERSEDED -->|"重来（相同 featureId）<br/>设置 parent/supersededBy"| ACTIVE
+
+```
+
+### publishChecklist failedItems 格式
+
+`failedItems` 数组中的每个条目遵循以下标准结构：
+
+|字段|类型|说明|
+|---|---|---|
+|`title`|string|**必填**。失败 Issue 的标题，与 4b 任务清单中的 Story 标题一致|
+|`fr`|string|关联的功能需求编号（如 `FR-3`），用于追溯 PRD 原文|
+|`priority`|string|优先级（`P0`/`P1`/`P2`），从 4b 任务清单继承|
+|`acceptance`|string[]|验收标准列表，从 PRD 验收标准章节提取|
+|`description`|string|Issue 详细描述，包含背景和预期行为|
+
+> 重试时 AI 依据 `title` 匹配任务清单中的条目，使用 `acceptance` 和 `description` 重建 Issue 内容。
+
+### 关联信息展示
+
+查看 `superseded` 状态的会话时，自动加载关联会话的信息一并展示：
+
+> 此会话（AUTH-LOGIN-TOKEN v1，tide-20260611-001）已被
+> 🔄 **AUTH-LOGIN-TOKEN v2**（tide-20260612-001）取代
+> 📄 PRD: tide-data/prds/tide-20260611-001-prd.md
+> 📎 知识库: {services.knowledgeBase.url / dingtalkUrl}
+> 🎯 工单: {services.issueTracker.urls / jiraUrls 列表}
+> 最新需求: 增加微信扫码登录（原: 仅密码登录）
+
+---
+
+## 角色定义
+
+5 个 BMAD 角色，按固定顺序进行：
+
+|顺序|ID|名称|必需？|说明|
+|---|---|---|---|---|
+|1|`analyst`|📊 业务分析师 Mary|✅ 必需|了解背景、痛点、竞品、目标用户|
+|2|`pm`|📋 产品经理 John|✅ 必需|功能范围、用户故事、优先级、验收标准|
+|3|`architect`|🏗️ 架构师 Winston|⬜ 可选|技术可行性、风险、系统影响|
+|4|`designer`|🎨 UX 设计师 Sally|⬜ 可选|交互方案、设计约束|
+|5|`po`|👑 产品负责人 Chris|⬜ 可选|业务价值、发布策略|
+
+**必需角色（2 个）：** `analyst`、`pm` — 必须完成才能生成 PRD
+**可选角色（3 个）：** `architect`、`designer`、`po` — 用户可以选择跳过

package/dist/skills/tide-discuss/references/prd-template.md

@@ -0,0 +1,134 @@
+# PRD 模板
+
+Step 3 生成 PRD 时使用的 Markdown 模板。
+
+---
+
+```markdown
+---
+title: {featureId} — PRD
+status: 讨论完成
+created: {日期}
+updated: {日期}
+featureId: {featureId}
+---
+
+# {featureId} — {brief}
+
+> 通过 Tide BMAD 工作流自动生成 | 会话 ID: {sessionId}
+
+## 1. 概述
+
+**需求描述:** {brief}
+**Feature ID:** `{featureId}`
+**参与角色:**
+- 📊 analyst — {summary 第一行}
+- 📋 pm — {summary 第一行}
+（如 architect / designer / po 已参与，在此列出）
+
+## 2. 背景与目标
+
+{analyst 的 summary}
+
+**关键决策:**
+- {analyst 的 decisions，包含背景分析和约束假设}
+
+**分析师需求（AR — Analyst Requirements）:**
+- AR-1: {analyst requirements，按背景/约束/假设分类}
+- AR-2: {analyst requirements}
+
+## 3. 用户故事
+
+{pm 的 requirements 中以"作为/我想/希望/用户"开头的条目}
+
+## 4. 功能需求
+
+{pm 的 requirements 中非用户故事的条目，编号 FR-1, FR-2...}
+
+## 5. 非功能需求
+
+- 可用性: 需满足基本可用标准
+- 性能: 响应时间在可接受范围内
+- 安全: 遵循数据安全和隐私保护规范
+
+## 6. 验收标准
+
+{pm 的 decisions 中属于验收标准的条目，编号 AC-1, AC-2...}
+
+## 7. 技术方案
+
+{如 architect 角色已讨论完成，写入总结和决策；如未讨论则写"（未讨论）"}
+
+## 8. UX 设计建议
+
+{如 designer 角色已讨论完成，写入总结和决策；如未讨论则写"（未讨论）"}
+
+## 9. 发布策略
+
+{如 po 角色已讨论完成，写入总结和决策；如未讨论则写"（未讨论）"}
+
+## 10. 讨论记录
+
+| 角色 | 完成时间 | 总结 |
+|------|----------|------|
+| {列出有 completedAt 的角色，跳过 skipped 的} | {时间} | {summary，前 50 字，不足则全量显示} |
+
+## 11. 开放问题
+
+- [ ] 需求范围是否有需要进一步明确的地方？
+- [ ] 所有关键决策是否已记录？
+- [ ] 验收标准是否覆盖了所有场景？
+```
+
+同时保存 JSON 快照到 `tide-data/prds/{sessionId}-prd.json`，格式如下：
+
+```json
+{
+  "sessionId": "tide-20260611-001",
+  "featureId": "AUTH-LOGIN-WECOM",
+  "brief": "企业微信扫码登录",
+  "generatedAt": "2026-06-11T10:30:00.000Z",
+  "participants": [
+    {"role": "analyst", "completedAt": "2026-06-11T10:15:00.000Z", "skipped": false},
+    {"role": "pm", "completedAt": "2026-06-11T10:25:00.000Z", "skipped": false}
+  ],
+  "sections": {
+    "background": {
+      "summary": "企业微信在内部通讯中使用广泛，目前缺乏与企业微信集成的登录方式...",
+      "decisions": ["使用扫码而非手动输入", "优先对接飞书而非企业微信"],
+      "analystRequirements": ["AR-1: 支持企业微信扫码登录", "AR-2: 登录页面适配移动端"]
+    },
+    "userStories": [
+      "作为企业微信用户，我想通过扫码快速登录，以便无需输入账号密码",
+      "作为 IT 管理员，我想配置企业微信登录参数，以便控制接入权限"
+    ],
+    "functionalRequirements": [
+      {"id": "FR-1", "title": "支持企业微信扫码登录", "priority": "P0"},
+      {"id": "FR-2", "title": "扫码授权页 UI", "priority": "P1"}
+    ],
+    "nonFunctionalRequirements": [
+      "可用性: 需满足基本可用标准",
+      "性能: 响应时间在可接受范围内"
+    ],
+    "acceptanceCriteria": [
+      {"id": "AC-1", "description": "用户可通过企业微信扫码完成登录"},
+      {"id": "AC-2", "description": "同一账号最多 3 台设备同时在线"}
+    ],
+    "technicalPlan": "（未讨论）",
+    "uxSuggestions": "（未讨论）",
+    "releaseStrategy": "（未讨论）"
+  },
+  "discussionRecords": [
+    {"role": "analyst", "completedAt": "2026-06-11T10:15:00.000Z", "summary": "讨论了企业微信在企业通讯录中的使用情况..."}
+  ],
+  "openQuestions": [
+    "需求范围是否有需要进一步明确的地方？",
+    "所有关键决策是否已记录？"
+  ]
+}
+```
+
+**说明：**
+- `sections` 中可选角色对应的字段（`technicalPlan` / `uxSuggestions` / `releaseStrategy`）如果角色未参与，值为 `"（未讨论）"`，与 Markdown 模板一致
+- `participants` 包含所有已参与的角色（包括 `skipped: true` 的），不含未触及的角色
+- 该 JSON 用于 4b 任务拆分的结构化读取，字段名固定不可随意修改

package/dist/skills/tide-discuss/references/publish-flow.md

@@ -0,0 +1,167 @@
+# 发布流程（Step 4）
+
+PRD 生成后（`status: prd_ready`），分三步完成发布流程。每步根据运行时 MCP 能力映射动态决定是否执行或跳过。
+
+## MCP 能力发现
+
+进入 Step 4 时，AI 先读取 `.claude/settings.json` → `deepstorm.mcpCapabilities` 确定可用的 provider。
+
+能力映射结构示例（安装时渲染）：
+```json
+{
+  "knowledge_base": {
+    "available": true,
+    "providers": [{ "id": "feishu-wiki", "label": "飞书知识库" }]
+  },
+  "issue_tracker": {
+    "available": false,
+    "providers": []
+  }
+}
+```
+
+### 可用性判定规则
+
+- `knowledge_base.available = true` → 4a 可执行
+- `issue_tracker.available = true` → 4b+4c 可执行
+- providers 数组长度 > 1 → 在该步骤入口询问用户选择
+
+### 引用 MCP skill 指南
+
+调用某 provider 的 MCP 工具前，AI 必须读取对应的 skill 指南了解工具调用方式。skill 路径规则为 `.claude/skills/deepstorm-mcp-{provider-id}-write/SKILL.md`（如 `feishu-wiki` → `deepstorm-mcp-feishu-wiki-write`、`jira` → `deepstorm-mcp-jira-write`），按指南执行操作。
+
+---
+
+## 发布进度跟踪
+
+每一步的完成状态记录在 session JSON 的 `publishChecklist` 字段中，支持断点续传：
+
+```json
+{
+  "publishChecklist": [
+    {"step": "knowledge_base_push", "done": true, "note": "已推送到知识库"},
+    {"step": "issue_task_split", "done": true, "note": "用户已确认 5 个任务"},
+    {"step": "create_issues", "done": false, "total": 5, "created": 3,
+     "failedItems": [
+       {"title": "Story 4: Token 刷新优化", "fr": "FR-4", "priority": "P1",
+        "acceptance": ["Token 过期后自动刷新", "刷新过程用户无感知"],
+        "description": "用户登录后获取 Token，Token 过期前自动调用刷新接口"},
+       {"title": "Story 5: 多设备登录管理", "fr": "FR-5", "priority": "P2",
+        "acceptance": ["同一账号最多 3 台设备同时在线", "超出时提示用户"],
+        "description": "用户可在多台设备上登录同一账号，系统管理设备会话数"}
+     ]}
+  ]
+}
+```
+
+**规则：**
+- `done: true` + 无 `skipped` → 该步已完成，下次恢复时直接跳过
+- `done: true` + `skipped: true` → 该步被跳过（无可用 MCP 服务）。恢复时**跳过该步**，不重新检查 MCP 可用性
+- `done: false` + 无 `failedItems` → 该步从未执行过，从头开始
+- `done: false` + 有 `failedItems` → 部分失败，仅重试 `failedItems` 中的条目
+- 每次恢复时 AI 查看 `publishChecklist`，跳过已完成步骤，只处理失败项或未执行项
+
+---
+
+## 4a. 知识库推送
+
+按能力映射可用性和 provider 数量动态执行：
+
+### 场景 A：单知识库可用（自动推送）
+
+1. **检查 PRD 文件存在性：** 读取 `tide-data/prds/{sessionId}-prd.md`。如果文件不存在，按优先级恢复：JSON 快照 → session steps 记录 → 重新生成 Markdown（详见 SKILL.md Step 3「异常处理」）
+2. 根据 `services.knowledgeBase.provider`（或 `deepstorm.mcpCapabilities.knowledge_base.providers[0].id`）确定 provider，读取 `.claude/skills/deepstorm-mcp-{provider-id}-write/SKILL.md` 了解工具调用方式
+3. 使用该 MCP 推送 PRD Markdown 到知识库
+4. 成功后：
+   - 保存 `services.knowledgeBase` → `{provider: "{provider-id}", url: "..."}`
+   - `publishChecklist[0]` → `{step:"knowledge_base_push", done:true}`
+   - `status` → `published`
+5. 告知用户 PRD 已发布到知识库
+
+### 场景 B：多知识库可用（用户选择）
+
+在 4a 入口展示可用列表让用户选择：
+```
+检测到多个知识库服务：
+1. {provider1.label} ({provider1.id})
+2. {provider2.label} ({provider2.id})
+请选择本次推送使用的知识库：
+```
+用户选择后，按所选 provider 的 skill 指南执行推送。选择结果持久化到 `services.knowledgeBase.provider`。
+
+### 场景 C：无可用知识库（跳过）
+
+1. `publishChecklist[0]` → `{step:"knowledge_base_push", done:true, skipped:true, note:"无可用知识库服务"}`
+2. `status` → `published`
+3. 告知用户"未检测到知识库服务，跳过 PRD 推送"
+
+### 场景 D：推送失败
+
+`publishChecklist[0].done = false`，`status` 改为 `publish_error`，提示用户错误信息，提供重试或放弃发布选项。
+
+---
+
+## 4b. 任务拆分
+
+### 有可用工单系统时
+
+1. 读取当前 PRD 的 Markdown / JSON 快照
+2. 将 PRD 内容拆解为可落地的工作项：
+   - **Epic：** `{featureId} — {brief}`（父级，包含完整背景和目标）
+   - **Story：** 每个 FR / 用户故事对应一个 Story，含验收标准
+   - **Task：** 较大的 Story 可拆成子 Task
+   - **优先级：** 根据 PRD 中的优先级排序标注
+3. 展示完整任务清单给用户确认，格式示例：
+   ```
+   📋 任务清单 — {featureId}
+
+   Epic: {featureId} — {brief}
+   ├─ Story 1: {title1}（FR-1）
+   │  ├ 验收标准: {ac}
+   │  └ 优先级: P0
+   └─ Story 2: {title2}（FR-2）
+      ├ 验收标准: {ac}
+      └ 优先级: P1
+   ```
+4. **让用户确认或调整**任务清单（增删合并、调整优先级）
+5. **用户确认后：** 将确认后的完整任务清单保存到 session JSON 的 `services.issueTracker.taskBreakdown` 字段（向后兼容：降级到旧字段 `jiraTaskBreakdown`）。`publishChecklist[1].done = true`，进入 4c
+6. **用户中止：** 如果用户不想继续确认（"先这样"、"后面再说"），保持 `published` 状态，`publishChecklist[1].done = false`。提示用户可以随时回到此会话继续确认
+
+### 多工单系统可用时（额外步骤）
+
+在 4b 入口询问用户选择：
+```
+检测到多个工单系统：
+1. {provider1.label} ({provider1.id})
+2. {provider2.label} ({provider2.id})
+本次使用哪个？
+```
+选择结果持久化到 `services.issueTracker.provider`，同一 session 内后续 4c 和恢复时直接读取，不再重新询问。
+
+### 无可用工单系统时（跳过 4b + 4c）
+
+- `publishChecklist[1]` → `{step:"issue_task_split", done:true, skipped:true, note:"无可用工单系统"}`
+- `publishChecklist[2]` → `{step:"create_issues", done:true, skipped:true, note:"无可用工单系统"}`
+- `status` → `completed`
+- 告知用户"未检测到工单系统，跳过任务拆分和 Issue 创建"
+- 自动归档
+
+---
+
+## 4c. 创建工单
+
+### 正常创建
+
+1. 优先从 session JSON 的 `services.issueTracker.taskBreakdown` 读取任务清单（向后兼容：降级到旧字段 `jiraTaskBreakdown`）。如不存在则从 PRD 重新生成
+2. 根据 `services.issueTracker.provider`（或 `deepstorm.mcpCapabilities.issue_tracker.providers[0].id`）确定 provider，读取 `.claude/skills/deepstorm-mcp-{provider-id}-write/SKILL.md` 了解工具调用方式
+3. 逐条创建 Issue
+
+### 失败处理
+
+- **部分失败：** 成功 URL 加入 `services.issueTracker.urls`（自动去重），`publishChecklist[2]` 记录 `{done: false, total: N, created: M, failedItems: [...]}`。`status` → `publish_error`。下次恢复时从 `taskBreakdown` 重建上下文，仅重试失败项
+- **全部失败：** `publishChecklist[2]` 记录全部条目为 `failedItems`。`status` → `publish_error`。提示用户检查 MCP 连接
+- **全部成功：** `publishChecklist[2].done = true`，移除 `failedItems`（避免残留过时数据），`total` 和 `created` 更新为成功总数。`status` → `completed`。自动归档
+
+### 恢复路径
+
+恢复 `published` 或 `publish_error` 状态的 session 时，AI 检查 `publishChecklist` 中的 `skipped` 标记，跳过已被跳过的步骤。已完成的步骤不重复执行。

package/dist/skills/tide-discuss/references/role-prompts.md

@@ -0,0 +1,105 @@
+# 角色引导 Prompts
+
+进入每个角色时作为系统提示参考。
+每个角色有对应的 checklist（`references/checklists.md`），必须逐项确认完成。
+
+### 行为边界（通用）
+
+所有角色共享以下行为规则：
+
+- **用户岔开话题** — 如果用户问到技术细节、其他需求、闲聊等不相关话题，先简要回应（不超过 1 句话），然后自然引导回来："我们先回到当前需求，关于 {checklist 当前项}……"
+- **用户想跳过（可选角色）** — 如果用户说"差不多"或想提前结束可选角色讨论，检查 checklist 是否有未完成项。若有，提示还有哪些要点未讨论。用户仍坚持跳过 → 标记 `skipped: true` **并设置 `completedAt`**，进入下一角色
+- **用户想跳过（必需角色）** — 如果用户对 analyst 或 pm 说"差不多"，检查 checklist 未完成项并追问。用户仍坚持结束 → 将未完成项标记为「已讨论」，**补全步骤记录**，设置 `completedAt`（**不设置 `skipped: true`**），进入下一角色
+- **用户拒绝讨论** — 如果用户明确说"这个角色不需要"或"别问这些了"：
+  - **可选角色：** 记录 `skipped: true` 并设置 `completedAt`，进入下一角色
+  - **必需角色：** 提示该角色为必选，至少完成核心项；用户仍拒绝 → 补全已讨论的内容为「已讨论」，设置 `completedAt`（**不设置 `skipped: true`**），进入下一角色
+- **用户问非当前角色的问题** — 如 analyst 阶段用户问"这个技术能不能实现"，记录为待办项，说"这个问题留给架构师 Winston 讨论"，回到当前角色话题
+
+---
+
+### 角色讨论通用结构
+
+所有角色进入后按以下流程执行，具体 checklist 项见 `references/checklists.md`：
+
+- **进入时：** 展示全部 checklist（全部 ⬜），然后逐一讨论
+- **完成时：** 确认全部 ☑️，保存 steps[]，进入下一角色
+- **跳过时（可选角色）：** 添加占位记录（skipped: true），继续下一角色
+
+---
+
+## 💼 分析师 Mary（必需）
+
+> 你现在扮演的是 **📊 业务分析师 Mary**。
+> 以 Porter 的战略严谨性和 Minto 金字塔原则，通过验证证据找到需求真相。
+>
+> **Checklist（5 项）：** `references/checklists.md` — analyst
+>
+> 目标：
+> - 了解需求背景和用户痛点
+> - 调研竞品和市场趋势
+> - 明确目标用户和使用场景
+>
+> 要求：基于证据和数据，避免主观臆断。完成所有目标后进入下一角色。
+>
+
+---
+
+## 📋 产品经理 John（必需）
+
+> 你现在扮演的是 **📋 产品经理 John**。
+> 以 Jobs-to-be-Done 为驱动，用户价值优先。
+>
+> **Checklist（5 项）：** `references/checklists.md` — pm
+>
+> 目标：
+> - 定义功能范围和边界
+> - 梳理用户故事和优先级
+> - 确定验收标准
+>
+> 要求：基于用户价值和实际场景。完成所有目标后进入下一角色。
+>
+
+---
+
+## 🏗️ 架构师 Winston（可选）
+
+> 你现在扮演的是 **🏗️ 架构师 Winston**（可选）。
+> 偏爱成熟技术以保持稳定。
+>
+> **Checklist（4 项）：** `references/checklists.md` — architect
+>
+> 目标：
+> - 评估技术可行性和实现成本
+> - 识别潜在技术风险和依赖
+> - 给出架构建议和约束
+>
+
+---
+
+## 🎨 UX 设计师 Sally（可选）
+
+> 你现在扮演的是 **🎨 UX 设计师 Sally**（可选）。
+> 共情与边缘情况严谨性并重。
+>
+> **Checklist（4 项）：** `references/checklists.md` — designer
+>
+> 目标：
+> - 评估用户体验影响
+> - 识别关键交互流程
+> - 给出 UX 建议
+>
+
+---
+
+## 👑 产品负责人 Chris（可选）
+
+> 你现在扮演的是 **👑 产品负责人 Chris**（可选）。
+> 对产品整体方向和业务价值负责。
+>
+> **Checklist（4 项）：** `references/checklists.md` — po
+>
+> 目标：
+> - 确认产品方向与战略对齐
+> - 评估需求优先级与投入产出比
+> - 确认发布策略和节奏
+>

package/package.json

@@ -0,0 +1,38 @@
+{
+  "name": "@deepstorm/cli",
+  "version": "0.1.0",
+  "description": "DeepStorm CLI — 一键配置项目开发环境",
+  "license": "MIT",
+  "author": "billkang",
+  "bin": {
+    "deepstorm": "./dist/cli.js"
+  },
+  "files": [
+    "dist/"
+  ],
+  "scripts": {
+    "build": "node scripts/build.mjs && node dist/build-registry.js",
+    "test": "vitest run --coverage",
+    "prepublishOnly": "npm run build",
+    "prepack": "npm run build"
+  },
+  "dependencies": {
+    "@clack/prompts": "^0.9.0",
+    "commander": "^12.0.0",
+    "handlebars": "^4.7.8",
+    "js-yaml": "^4.1.0"
+  },
+  "devDependencies": {
+    "@types/node": "^22.0.0",
+    "@vitest/coverage-v8": "^4.1.0",
+    "esbuild": "^0.28.1",
+    "lightningcss": "^1.32.0",
+    "lightningcss-darwin-arm64": "^1.32.0",
+    "typescript": "^5.6.0",
+    "vite": "^8.0.16",
+    "vitest": "^4.1.9"
+  },
+  "publishConfig": {
+    "access": "public"
+  }
+}