cawplan-plan-create

CawPlan 计划创建

初始化

cawplan skill check

入口路由

输入	流程
明确的版本名称 + 可选的明确工单列表	A — 直接创建
粘贴的 OKR / 阶段目标，并要求据此生成计划	B — OKR 驱动的计划

工单字段语义

创建或更新每个工单时，使用 description 填写简短的标题/摘要，使用 remarks 填写详细页面的描述/正文（支持 HTML）。切勿将较长的描述正文放入 description。

工作流 A — 直接创建

1. 将产品名称解析为 product_id：

   cawplan products list --search "<product name>"
   

   只有在名称与可访问名称精确匹配（去除首尾空格后不区分大小写）、与唯一的简称/令牌前缀匹配，或用户明确确认了列出的候选项后，才继续。如果用户指定的产品不存在或不明确，请列出候选项（名称 + product_id）并询问用户指的是哪个产品；不要猜测或创建任何内容。如果存在多个匹配项，请让用户选择。无论是从工作流 A 还是工作流 B 进入，均适用此规则。

2. 创建版本：

   cawplan versions create <product_id> --name <X.Y.Z> --description "<goals>"
   

3. 如果用户提供了工单或任务，请在新版本中创建这些内容：

   cawplan tickets create-version <product_id> <version_id> \
     --description "<ticket title/summary>" \
     --remarks "<html body>" \
     --type FEATURE --priority MEDIUM
   

   对每个工单重复此操作。仅当用户提供工单正文详情时才包含 --remarks；该字段支持 HTML。如果用户提供了受理人，请使用 cawplan users query --email <email> 解析。

工作流 B — 以 OKR 为驱动的计划

CawPlan 的工单架构中没有任何工作量估算或故事点字段——此处的任何估算都只是 LLM 的粗略猜测，绝非权威数字，并且每次显示时都必须明确标注为猜测。

1. 解析产品（工作流 A 步骤 1）并获取目标版本名称——规则与工作流 A 相同：如果用户未提供，就询问；绝不自行编造。
2. 获取现有待办列表，以便去重：

   cawplan backlog list <product_id> --page_size 100
   

   完整翻页——待办列表不完整会导致去重不可靠，而不只是有所遗漏。响应是 CommonPageResp（包含 data、page_num、page_size、total）；当 page_num * page_size < total 时，持续递增 page_num，不要因为某一页已满就只取一页后停止。对于步骤 4 和 6，保留每个结果的 unique_id（不是 display_id——显示 ID 用于向用户展示，API 调用需要 unique_id），以及当前的 type/priority。
3. 从用户粘贴的 OKR/目标中提取候选工作项——文本实际陈述的每个不同目标/举措对应一张工单。不要编造源文本中没有的范围、子任务或验收标准；如果某个目标过于模糊，无法转化为具体工单，就将其列为问题交给用户，而不是猜测。
4. 与待办列表去重，逐项按含义而非精确字符串匹配：
   • 强匹配（待办项显然是同一项工作）→ 不要创建重复工单。计划将现有待办工单移入新版本（见步骤 6）；沿用步骤 2 中保留的 unique_id、type 和 priority——已移动工单的预览行应反映其当前实际属性，而不是工作流 A 的 FEATURE/MEDIUM 默认值（这些默认值仅适用于真正的新工单）。
   • 部分重叠/不确定 → 将 OKR 项视为新工单，但同时标记相关待办项，注明“可能相关——值得人工检查”，不要默默合并可能并非同一项的内容。将此标记写入新工单的 --remarks，不能只显示在预览中——聊天会话结束后也应保留此标记。
   • 无重叠 → 新工单，不加标记。
5. 对每个新工单候选项添加粗略工作量估算，并明确标注为猜测（例如，在备注或预览中写“~M 粗略估算，未经核实”——不能写成确定的数字），只能依据源文本所描述的范围进行估算。
6. 创建任何内容之前先预览——此步骤涉及解读（目标 → 工单）和复用决策（移动还是创建），两者都有可能被误解。显示版本名称，以及每个候选项的标题、类型、优先级、粗略估算，以及该项属于“新建”还是“移动现有待办工单 <display_id>”。运行任何创建/更新命令前，必须获得用户明确确认。
7. 确认后：
   • 创建版本（工作流 A 步骤 2）。
   • 对于“新建”候选项：使用 cawplan tickets create-version（工作流 A 步骤 3），并遵循相同的字段约定。
   • 对于“移动现有”候选项：按照约定，待办工单的 version_id 等于其自身的 product_id（这正是其属于“待办”而非归属某个版本的原因——参见 references/CAWPLAN_OPEN_API.md 中关于待办工单的说明），因此使用：

     cawplan tickets update <product_id> <product_id> <backlog_ticket_unique_id> --target_version_id <new_version_id>
     

     使用步骤 2 中保留的 unique_id，而不是显示 ID。移动而非重复创建，可以保留工单的历史记录。

规则

• 如果用户未提供版本名称，就询问。不要编造或自动递增版本号。
• 创建前必须提供符合 X.Y.Z 格式的确切版本名称。
• 如果需要 --major_id（用于关联主要版本），先解析它：

  cawplan versions list <product_id>
  

• 除非另有说明，工单类型默认为 FEATURE，优先级默认为 MEDIUM。
• 只有在用户明确描述工单（工作流 A），或 OKR/目标文本确实陈述了工单（工作流 B）时，才创建工单。

确认

创建版本后，请报告：

• 版本名称和唯一 ID。
• 产品名称和 ID。
• 描述（过长时请截断）。
• 已创建工单列表（显示 ID、类型、标题／摘要，以及备注（如有））；如果没有创建工单，请写“未创建工单”。
• 对于工作流 B：还要列出哪些工单是从待办列表中移入的（注明其原始显示 ID），哪些是新创建的；并在摘要末尾再次说明粗略估算的注意事项，而不只是出现在预览中。

参考资料

• references/CAWPLAN_OPEN_API.md