cawplan-ticket-create

CawPlan チケットの作成

ブートストラップ

cawplan skill check

エントリールーティング

何かを始める前に、フローを選択します。

入力	フロー
明示的な単一チケットの依頼（「X のチケットを作成して」「Y のバグを起票して」）	A — 単一チケット
貼り付けられた PRD、要件ドキュメント、Slack スレッド、会議の書き起こし／メモ。「これをチケットにして」という明示的な依頼の有無は問いません	B — テキストから抽出
「X をサブチケットに分割して」「拆分 sub-tickets」、または親チケット（既存の CawPlan チケット、あるいは先に作成するチケット）の下にチケットを作成する依頼	C — サブチケットに分割

メッセージに両方が混在している場合（明示的な依頼と大量の貼り付けコンテキストがある場合）は、B として扱い、元の情報から判断できるのが 1 件だけなら、抽出結果として単一チケットを作成します。親チケットが指定されている場合、または抽出した項目をサブチケットにするよう求められている場合は、B で抽出してから、C でチケットを起票します。

ワークフロー A — 単一チケット

ユーザーがプロダクトを指定した場合は、バージョンも指定されている場合を含め、使用する前に必ず解決します。完全一致するアクセス可能な名称（空白を除去した後、大文字小文字を区別しない）、一意な短縮形／トークンのプレフィックス、またはユーザーが明示的に確認した候補を受け入れます。指定されたプロダクトが見つからない、または曖昧な場合は、候補を列挙してどのプロダクトを指しているのか確認します。名称が似ているだけで一意でないプロダクトに対してチケットを作成してはいけません。確認後、以降のコマンドでは解決済みの product_id を優先して使用します。

プロダクトが指定されているものの、バージョンが指定されていない場合：

1. まずプロダクトを解決します。

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

   上記のプロダクト解決ルールに従います。プロダクトが確認されていない場合は、バージョンの一覧表示もチケットの作成も行いません。
2. 解決済みのプロダクトのバージョンを一覧表示します。

   cawplan versions list <product_id> --page_size 100
   

3. 進行中のバージョン（IN_PROGRESS、INPROGRESS などの status／state、または表示テキストの「In Progress」）をユーザーに提示し、1 つ選んでもらいます。「バックログ／バージョンなし」の選択肢を提示するのは、ユーザーがバージョンを指定できない場合の代替手段に限ります。

作成前に確認すること — プロダクト／バージョンがすでに指定された明示的な単一チケットの依頼であっても例外ではありません。解決済みの Product、Version（または「Backlog」）、Title、Type、Priority、Assignee（または -）をユーザーに提示し、以下の作成コマンドを実行する前に明示的な承認を得ます。この CLI からチケットの作成を取り消すことはできません（tickets delete はありません）。そのため、依頼がすでに確定した内容に見えても、この確認を省略してはいけません。

バージョン付きチケット（特定のバージョンを対象とする場合）：

cawplan tickets create-version \
  --product "<product name>" \
  --ver "<version name>" \
  --description "<ticket title>" \
  --remarks "<html description body>" \
  --type FEATURE \
  --priority MEDIUM \
  --reporter <your-email> \
  --assignee <email>

バックログチケット（ユーザーがバージョンを指定できない場合、またはバックログを明示的に希望した場合に限る）：

cawplan tickets create-backlog \
  --product "<product name>" \
  --description "<ticket title>" \
  --remarks "<html description body>" \
  --type FEATURE \
  --priority MEDIUM \
  --reporter <your-email>

--reporter に使用する自分のメールアドレスを取得します。

cawplan auth status   # shows authenticated email

チケットを作成するには OAuth ログインが必要です。

ワークフロー B — 貼り付けられたテキストからチケットを抽出

会話に直接貼り付けられた PRD、Slack スレッド、会議の書き起こしを対象とします。単純なコピー＆ペーストであり、アップロードや Slack／会議との連携はありません。

1. 作成先のスコープを解決します — 1 つのプロダクトか、プラットフォームごとにプロダクトが分かれた Team かを確認します：
   • 単一のプロダクト（一般的なケース）：Workflow A と同じ方法で解決し、そのプロダクトのバージョンを 1 つ解決します（進行中のバージョンを一覧表示してユーザーに選んでもらうか、バックログを確認します）。テキストにバージョンが記載されている場合はそれを使用し、記載されていない場合は質問します。特定の項目で別のプロダクトやバージョンが明示されていない限り、抽出したすべての候補にこのプロダクトとバージョンを適用します。
   • プラットフォームごとに異なるプロダクトに分かれた Team（例：「VN Team に追加。FE／BE／iOS／Android は別々のプロダクト」）—作成先は 1 つのプロダクトではないため、通常のプロダクト検索では解決できません：
     1. Team 名を product_line_id に解決します（cawplan-product-report の Team ワークフローと同じく、ページ分割して取得し、クライアント側で名前を照合します）。完全一致（空白をトリミングした後、大文字と小文字を区別しない）、一意の短縮形／トークン接頭辞一致、または一覧にある候補についてユーザーが明示的に確認した場合に限り、Team を確定します。指定された Team が存在しないか、候補が曖昧な場合は、候補を一覧表示してどの Team を指すのか尋ねます。プロダクトを一覧表示したり、最も近そうな Team を推測したりしてはいけません：

        cawplan product-lines list --page_size 100
        

     2. その Team のプロダクトを一覧表示します：

        cawplan products list --product_line_id <product_line_id>
        

     3. 抽出対象となる各プラットフォーム（FE／BE／iOS／Android、および QA）を、一覧にあるどのプロダクトに対応させるかユーザーに尋ねます。プロダクト名だけから対応関係を推測してはいけません。「VN Cloud」や「VN Roadmap」のような名前だけでは BE か FE か明らかではなく、誤って推測すると実際の作業を誤ったプロダクトに気づかれないまま登録してしまいます。ユーザーが QA 用のプロダクトを指定しない場合は、勝手に決めず、QA チケットの作成先を尋ねます。Team に QA 専用プロダクトがないことはよくあるため、QA 作業は通常、他の対応済みプロダクトのいずれかに追加するか、スキップしますが、どちらにするかは推測できません。
     4. 手順 2 の一覧から、対応付けた各プロダクトの product_id を名前と一緒に直ちに記録します — 作成時に products list --search で名前から再解決してはいけません。実環境で確認したところ、このシステムの実際のプロダクト名に不規則な二重スペース（「VN: iOS」）が含まれており、通常の名前検索では一致せず、tickets create-version --product "<name>" が失敗しました。手順 2 の一覧には候補すべての正確な product_id が含まれています。以下の手順 4～5 でもその ID を引き継ぎ、作成時には表示名ではなく --product <product_id> を渡してください。そうすれば、プロダクト名のデータ入力上の些細な問題でチケット作成が失敗することを防げます。
     5. 対応付けで使用する各プロダクトについて、Workflow A と同じ方法でバージョンを 1 つ解決します（進行中のバージョンを一覧表示してユーザーに選んでもらうか、バックログを確認します）。バージョンは Team ではなくプロダクトに属するため、バッチ全体で一度ではなく、実際に使用するプロダクトごとに一度ずつ行います。
     6. このプラットフォーム→プロダクト／バージョンの対応付けを手順 2 に引き継ぎます。各候補のプロダクト／バージョンには、共通のプロダクトではなく、その候補のプラットフォームに対応付けられたものを使用します。
2. ソーステキストのみからチケット候補を抽出します：
   • PRD／要件定義書 → 文書で実際に指定されている対象プラットフォーム／コンポーネントごとに 1 件のチケットを作成します（例：FE／BE／iOS／Android／QA）。文書にプラットフォーム別の内訳がなく、1 つのまとまった作業として記述されている場合は、チケットを 1 件だけ作成します。分割を勝手に考案してはいけません。前の手順で Team モードを選んだ場合は、各候補に、そのプラットフォームに対応付けたプロダクト／バージョンを設定します。
   • Slack のスレッド／会議の文字起こし → 個別のアクションアイテムごとに 1 件のチケットを作成します。実際のアクションアイテムとは、（a）確定的で無条件の担当表明（「X が Y を行います」、「私が対応します」、または具体的なフォローアップを伴う決定）、または（b）担当者がいなくても、具体的に説明されたバグ／問題（特定の症状、発生条件、または再現条件があるもの）のいずれかです。条件付きの申し出や将来の申し出（「根本原因がわかったら手伝えます」など）は担当者の設定には使えませんが、具体的なバグそのものを無効にはしません。質問だけで決定事項がない発言、「単なる興味です」という補足、フォローアップなしに担当を明示的に否定する発言など、単なる雑談は、既知の問題領域に言及していてもアクションアイテムではありません。
   • スレッド内で以前の発言が撤回または訂正されている場合（「やっぱり違います。Y ではなく X だと思います」など）は、訂正後の最終版のみを使用します。話者が撤回した主張からチケットを作成してはいけません。
   • ソーステキストにないチケット、担当者、詳細を捏造してはいけません。ソースが曖昧すぎて明確な項目に整理できない場合は、分割を推測せず、確認の質問をしてください。
3. 各候補をチケットのフィールドに割り当てます：
   • description（タイトル）：文字起こしからそのままコピーせず、独自の言葉で簡潔に要約します。
   • remarks（本文）：関連する抜粋／背景情報を HTML に変換します（ルールを参照）。
   • type：デフォルトは FEATURE とし、明らかなバグ／欠陥である場合にのみ BUGFIX とします。
   • priority：デフォルトは MEDIUM とします。ソースで緊急度の高さが示されている場合は HIGH／CRITICAL に引き上げ、緊急ではない、または後回しにできると明示されている場合は LOW に下げます。
   • assignee：確定的で無条件の担当表明がある場合（上記参照）に限り、さらに cawplan users query --keyword "<name>" で名前が 1 人に一意に解決された場合にのみ設定します。確定的な担当表明がない場合、または検索結果が 0 件もしくは複数件の場合は未割り当てにします（プロダクト／バージョンと同じ曖昧さの解消ルールを適用し、ユーザーに尋ねます）。
   • プラットフォームラベル：ユーザーがプラットフォーム別の分割を依頼し、かつ一致するラベルが存在する場合にのみ適用します。次のコマンドで確認します：cawplan labels list --product_id <product_id> --search "<platform>"（Team モードでは、共通の product_id ではなく各候補に対応付けられた product_id を使用します）。ラベル名を勝手に考案してはいけません。一致するものがない場合は、ラベルを付けずにタイトル／備考にプラットフォームを記載します。Team モードでは、候補がどのプロダクトに登録されるかによってプラットフォームがすでに示されているため、ラベルはあれば便利ですが、振り分けの代わりにはなりません。
4. **作成前にプレビューします。**複数チケットへの抽出は明示的ではなく推測を伴うため、ユーザーのメッセージにすでに「これらのチケットを作成して」と書かれていても、作成コマンドを実行する前に必ず候補一覧を提示し、ユーザーの確認を得ます。元の依頼ではなく、抽出した候補一覧の確認を得てください。ソーステキストの言語にかかわらず、ユーザーが使用している言語で一覧を提示します。
   • 単一プロダクトモード：適用されないフィールドには - を使い、「タイトル | 種別 | 優先度 | 担当者 | プラットフォーム」の形式で表示します。
   • Team モード：プラットフォーム→プロダクトの振り分けを作成前にユーザーが確認できるよう、プロダクト列を追加します。対応付けたプロダクト間でバージョンが異なる場合は、バージョン列も追加します。この振り分けは最も気づかれないまま間違いやすいため、プレビューから省略してはいけません。
5. 確認を得たら、Workflow A と同じ tickets create-version／tickets create-backlog コマンドを使い、候補ごとに 1 回ずつループしてチケットを作成します。Team モードでは、各コマンドで共通の組み合わせではなく、その候補に対応付けられた --product／--ver を使用します。

ワークフロー C — サブチケットに分割する

サブチケットは、--parent_id <parent> を指定して作成する通常のチケットです。--parent_id には親チケットの一意の ID または表示 ID（例：CWP-14556）を指定できます。CLI が表示 ID を解決します。

1. 親チケットを解決します。
   • 既存の親チケット（URL、表示 ID、一意の ID）：検索して、unique_id、display_id、product_id、version_id、description（タイトル）、remarks（本文）を保持します。

     cawplan tickets search --display_ids CWP-14556
     

     一致するものがなければ、その旨を伝えて停止します。別のプレフィックスを推測してはいけません。
   • 新しい親チケット：ワークフロー A とまったく同じように商品／バージョンを解決して作成し（作成前に必ず確認するゲートも同じです）、返されたチケットを親として使用します。
2. サブチケットを導き出します。 ユーザーが提供した内容（明示的なリスト、親チケットの remarks、または貼り付けられたテキスト。抽出ルールはワークフロー B を適用）に基づきます。独立して納品可能な項目ごとにサブチケットを作成します。元の内容で裏付けられていない項目を作り出してはいけません。分割が明確でない場合は、確認の質問を1つしてください。
3. スコープ： デフォルトでは、すべてのサブチケットを親チケットと同じ商品およびバージョンにします。ユーザーが希望した場合に限り、異なる商品／バージョンを使用します（例：ワークフロー B の Team モードでのプラットフォーム振り分け）。サーバーは、親チケットの商品ラインに含まれない商品のサブチケットを拒否します。また、親チケットの階層は最大5段階です。
4. 作成前にプレビューします — ユーザーがすでに「作成して」と言っていても、必ず行います。親チケット（表示 ID＋タイトル）と、タイトル｜タイプ｜優先度｜担当者｜商品／バージョン（親チケットと同じ場合は -）の表を表示し、確認を待ちます。
5. 作成 — 親チケットの ID を指定して、サブチケットごとに1回呼び出します。

   cawplan tickets create-version \
     --product <parent product_id> \
     --ver <parent version_id> \
     --parent_id <parent unique_id or display_id> \
     --description "<sub-ticket title>" \
     --remarks "<html body>" \
     --reporter <your-email>
   

   バックログの親チケット（is_backlog: true）の場合は、代わりに tickets create-backlog --product <product_id> --parent_id ... を使用します。

ルール

• デフォルトのタイプは FEATURE です。ユーザーがバグ、不具合、または問題と言った場合に限り BUGFIX を使用します。
• 指定がない場合のデフォルト優先度は MEDIUM です。
• タイトルと説明／本文は分けてください。
  • CLI の --description はチケットのタイトル／要約にのみ使用します。
  • CLI の --remarks はページの説明／本文に使用します。HTML に対応しており、通常ユーザーが「説明」と呼ぶのはこのフィールドです。
  • 長い本文、受け入れ条件、PRD のテキスト、複数行の説明を --description に入れてはいけません。
• プレーンテキストの本文は、--remarks に渡す前にコンパクトな HTML に変換します。改行区切りのテキストをそのまま渡してはいけません。1つの混在した行として表示される場合があります。必要に応じて <p>、<br>、<ul>、<li> を使用します。
• ユーザーが複数行の依頼（ワークフロー A）を提供した場合は、最初の短い行、または簡潔な要約をタイトルにし、残りの詳細を HTML の --remarks に入れます。タイトルを安全に特定できない場合は、確認の質問を1つしてください。
• ユーザーがバージョンを指定していない場合は、商品を解決し、進行中のバージョンを一覧表示して、チケットを作成する前にユーザーに選択してもらいます。
• デフォルトではバックログチケットを作成しません。create-backlog を使用するのは、ユーザーが明示的にバックログ／バージョンなしを希望した場合、またはバージョンを提示できないことを確認した後に限ります。
• バックログチケットを作成した場合は、ユーザーに「このチケットはバックログ項目として作成され、どのバージョンにも割り当てられていません。」と伝えます。
• チケットのタイトル／要約を推測してはいけません。タイトルがない場合は、確認の質問を1つしてください。
• 商品、バージョン、担当者の検索で CLI が複数の候補を返した場合は、ユーザーにどれかを指定してもらいます。

確認

作成後、以下を報告してください。

• チケットの表示 ID と一意 ID。

• 製品／バージョンの対象範囲（または「バックログ」）。

• 種類、優先度、ステータス。

• 担当者。いない場合は -。

• タイトル（CLI の --description の値。長い場合は HTML を除去して切り詰めます）。

• 説明／本文（CLI の --remarks の値。長い場合は HTML を除去して切り詰めます）。ない場合は -。

• サブチケットの場合は親チケット（表示 ID ＋タイトル）。該当しない場合は -。

ワークフロー C では、親チケットを最初に報告し、その後に作成したサブチケットを 1 行ずつ報告してください。

ワークフロー B では、作成したチケットを 1 行ずつすべて列挙し、プレビュー中にユーザーが除外または編集した候補も報告してください。チームモードでは、製品ごとに報告をまとめてください（各チケットの「製品／バージョンの対象範囲」の行に製品が記載されていますが、分類すると、プレビューでユーザーが確認したプラットフォームから製品への振り分けが反映されているか、簡単に確認できます）。

参照資料

• references/CAWPLAN_OPEN_API.md