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 を増やし続けてください。1 ページ分の結果がいっぱいだったとしても、そこで止めないでください。ステップ 4 と 6 で使うため、各結果の unique_id（display_id ではありません。表示 ID はユーザーに見せるためのもので、API 呼び出しには unique_id が必要です）と、現在の type／priority を保持してください。
3. 貼り付けられた OKR／目標から候補の作業項目を抽出します。テキストに実際に記載されている、明確に異なる目標／取り組みごとにチケットを 1 件作成します。元のテキストにないスコープ、サブタスク、受け入れ条件を作り出さないでください。目標が曖昧すぎて具体的なチケットにできない場合は、推測するのではなく、ユーザーへの質問として列挙してください。
4. 各候補について、完全一致ではなく意味に基づいてバックログとの重複を判定します。
   • 強い一致（バックログ項目が明らかに同じ作業を指している）→ 重複チケットを作成しないでください。代わりに、既存のバックログチケットを新しいバージョンに移動する計画を立てます（ステップ 6 を参照）。ステップ 2 で保持した既存の unique_id、type、priority を引き継いでください。移動するチケットのプレビュー行には、ワークフロー A の FEATURE／MEDIUM のデフォルトではなく、そのチケットの現在の内容を反映します（これらのデフォルトは、本当に新しいチケットにのみ適用されます）。
   • 部分的に重なる、または判断が不確かな場合 → OKR 項目を新しいチケットとして扱います。ただし、重複する可能性があるバックログ項目も併記し、「関連する可能性があります — 手動で確認することを推奨」としてフラグを付けます。実際には同一でない可能性のある 2 つの項目を、黙って統合しないでください。このフラグはプレビューだけでなく、新しいチケットの --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>
     

     表示 ID ではなく、ステップ 2 で保持した unique_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