cawplan-my-work

CawPlan の自分の作業

ブートストラップ

cawplan skill check

ワークフロー

1. 自分の user_id を特定します。これはローカルのアクセストークンからデコードされるため、ネットワーク呼び出しは不要です。

   cawplan auth status
   

   出力から User ID: の行を読み取ります。この行がない場合は、cawplan users query --email にフォールバックするのではなく、再認証します（cawplan auth login を実行し、表示された URL をユーザーに提示して、ユーザーの承認後に cawplan auth login --device-auth --complete を実行します）。auth status ですでに取得できる情報の特定にネットワーク呼び出しを使うことになるためです。

2. 自分の ToDo を取得します。

   cawplan todos user <user_id>
   

   ここでは、tickets（product_line → product → version の順にグループ化）、critical_issues（product_line → product の順にグループ化）、summary が返されます。デフォルトではステータスによる絞り込みは行われません。未完了の項目だけでなく、自分に割り当てられたすべての項目が応答に含まれます。

3. ユーザーが特定のプロジェクト／バージョンを指定した場合は、tickets をその product → version の末端に絞り込みます。critical_issues にはバージョンの次元がなく（product_line → product のみ）、同じ粒度には絞り込めません。そのため、ユーザーがバージョンを指定した場合は、critical_issues を該当する product のみに絞り込み、これらの重大な問題は製品全体に関わるものであり、指定されたバージョン固有のものとは確認されていないことを明示します。指定されたプロジェクト／バージョンが tickets のどこにも見当たらない場合は、すべての項目を表示するのではなく、「 にはあなたのチケットが見つかりませんでした」と明示します。

4. ユーザーが未完了の項目のみを求めている場合は、応答に含まれるすべての異なる製品ラインについてステータスカテゴリを解決し、適切に絞り込みます。これは自分で行う作業なので、現実的には数本のラインにとどまり、近道をするほどのことではありません。

   cawplan product-lines statuses <product_line_id>   # once per distinct product line in the response
   

   ステータスキーが COMPLETE または CANCELED カテゴリに対応するチケットを除外します。解決が妥当でないほど多くの製品ラインにまたがる場合（自分の作業であればまれです）に限り、「すべての項目のステータスを明確に表示し、ユーザーに判断してもらう」という方法に切り替えます。その場合は、絞り込みを行ったかのように未絞り込みの一覧を黙って提示するのではなく、その方法を取っていることを明示します。

5. 優先度順のフラットな一覧（ユーザーがプロジェクト／バージョン別の内訳ではなく、「優先度順の自分の未完了チケット」または優先度順の並べ替えを求めた場合のみ）：すべての製品ライン／製品／バージョンにわたる tickets を1つの一覧にまとめます。この形式は、明示されていなくても未完了のみを意味します。そのため、手順4の絞り込みを行います。その後、CRITICAL → HIGH → MEDIUM → LOW の順に並べ替えます。各行には引き続き、チケットが属する製品／バージョンを表示します。並べ替えのためにグループ化を解除しても、その情報を省略するわけではありません。

5a. 1日または期間のタスク完了状況／ステータス変更の要約（ユーザーが「帮我总结今天的任务完成情况」、「今天哪些任务状态变更了」または同等の依頼をした場合のみ）：これは手順2の現在の ToDo 一覧ではありません。デフォルトでは今日を対象期間とし、日付／期間が明示されている場合はそれに従います。

cawplan tickets search --assignees <user_id> --start_date 2000-01-01 --end_date <today> --updated_start_date <window_start> --updated_end_date <today> --page_size 100 --page_num 1

total を使って最後までページを取得します。updated_at の期間は候補を絞るためだけに使います。子チケットが変更されたことで親チケットが更新されても、親チケット自身のステータスは変わっていない場合があります。 次に、候補のステータス変更をまとめて取得します。1回の呼び出しにつき最大50個の ID を指定します。

cawplan tickets changes --unique_ids <candidate_ids_csv> --fields status --start_date <window_start> --end_date <window_end>

返されるイベントはすべて、期間内に実際に発生したステータス変更です（at、old → new、new_category）。イベントが1つ以上あるチケットのみを残します。updated_at を最終的な証拠として使ってはいけません。各チケットは1回だけ報告し、期間内で最新のイベントを使います。変更のない親チケットにはイベントがないため、子チケットの遷移によってレコードが更新されていても除外します。

フォールバック（tickets changes が利用できない場合のみ。「references/QUERY_RESILIENCE.md」を参照）： 候補ごとに cawplan tickets history <product_id> <version_id> <ticket_id> を取得し、期間内の created_at を持つ UPDATED エントリに changed_fields.status（新しいステータス文字列、または {old, new} オブジェクト）が含まれている場合のみ、チケットを残します。CREATED はステータス変更ではありません。 6. 再オープンされた自分のチケット（ユーザーが再オープンされたチケットや、何かが再オープンされた理由について尋ねた場合のみ）：REOPENED というステータス カテゴリ はありません（UNSTARTED／STARTED／TESTING／COMPLETE／CANCELED のみです）。再オープンは、その名前で示されるステータス キー、または終端カテゴリから後戻りする履歴上の遷移として現れます。履歴の確認（箇条書き2）が常に正確な情報源です。ステータスキーの確認（箇条書き1）は、チケットが現在再オープン用のステータスになっているよくあるケースでのみ使える近道であり、履歴の確認に代わるものではありません。

• 共有の定義と references/QUERY_RESILIENCE.md（「Reopens」）にあるコマンドを使って、現在のステータスにかかわらず、自分のチケットをすべて確認し、再オープンを見つけます。--unique_ids <ticket_ids_csv>（1 回の呼び出しにつき最大 50 ID）で呼び出しの対象を絞り、デフォルトでは直近 90 日間（--start_date <today-89d> --end_date <today>）を対象にします。そのことを伝え、ユーザーがそれより前の再オープンについて尋ねた場合にのみ、さらに前の 90 日間の期間を追加します。特定のチケットについて、その変更を分類できなかった場合は、2 つのカテゴリフィルターを外して再実行し、イベントを順に確認します。フォールバック（tickets changes が利用できない場合のみ）：チケットごとに cawplan tickets history <product_id> <version_id> <ticket_id> を実行します。
• ラベル付けの補助としてのみ、製品ラインごとにステータスを取得します（cawplan product-lines statuses <product_line_id>）。再オープン遷移直後のチケットのステータスの display_name に「reopen」が含まれているかを確認します。含まれている場合は、レポートでその名前を使って「再オープン」と記載できます。含まれていない場合（たとえば、in_progress や TESTING に直接戻った場合）でも、履歴上の遷移に基づけば再オープンです。専用のラベルがあると決めつけず、実際のステータス名を報告してください。
• 各再オープンイベントについて、履歴エントリにあればタイムスタンプと実行者を報告し、理由を示します。ステータス変更イベントについて API が履歴エントリ自体のコメントを返し、それがその遷移についてのコメントだと考えられる場合は、それを使います（遷移と結び付いていない一般的な自由記述のコメントを、再オープンの理由であるかのように示してはいけません）。それ以外の場合は、チケットの progress_comment を使い、「最新の進捗メモであり、必ずしも再オープンの理由ではありません」と明記します。どちらも存在しない場合は、理由は記録されていないと伝えます。チケットのタイトルや説明から理由を推測してはいけません。あるチケットの変更確認に失敗した場合は、「再オープンは見つからなかった」や理由が記録されていない証拠としてではなく、部分的な結果として「未確認」と記載します（references/QUERY_RESILIENCE.md を参照）。

7. チケットに紐づくリポジトリのPR／コミット（依頼された場合のみ — 「今日のチケットとそれぞれのPR／コミット」、「我当天任务涉及的tickets和PR/commit」）：チケットには、GitHubのPR／コミットURLを格納できる links[] 配列があります（形式は references/CAWPLAN_OPEN_API.md の「VersionTicket fields of note」に記載されています）。todos／poll ではこのフィールドは返されず、チケットの完全なレコードでのみ取得できるため、この手順では手順1〜6の todos 呼び出しではなく、tickets search を使用します。

   cawplan tickets search --assignees <user_id> --start_date 2000-01-01 --end_date <today> --updated_start_date <date> --updated_end_date <date> --page_size 100 --page_num 1
   

   ユーザーが別の日付／期間を指定していない限り、--updated_start_date／--updated_end_date の両方で、既定の <date>-<date> は今日にします。結果セットから別の解釈が必要だと分からない限り、終了日はその日の全体を含むものとして扱います。「今日のチケット」には --start_date／--end_date ではなく、--updated_start_date／--updated_end_date を使用します。前者はチケットの作成時刻を絞り込むためです（references/CAWPLAN_OPEN_API.md を参照し、example-backend のDAOで確認済みです）。そのため、先週作成され、今日も作業中のチケットが見落とされます。エンドポイントでは作成日時の期間または --time_range が必須なので、--start_date／--end_date も渡す必要があります。結果を絞り込まないよう、最大期間を使う回避策として 2000-01-01 から今日までを指定します。 リンクの platform は固定値として信頼できません。同じ手動追加のGitHubリンクでも platform: "LINK" と表示されることがあります。そのため、url 自体で分類します。/pull/ を含む場合はPR、/commit/ を含む場合はコミット、それ以外は title とともに通常のリンクとして報告します。links 配列が空のチケットにはリポジトリへのリンクがありません。報告から省略せず、その旨を伝えてください。 1ページに100件あればすべて取得できると仮定せず、レスポンスの total／page_num／page_size フィールドを使ってページを順に取得します（page_num * page_size < total の間は取得を続けます）。

8. PR／コミットが紐づいているのに、ステータスが更新されていないチケット（依頼された場合のみ — 「哪些ticket已经有PR/commit但状态还没更新」）：手順7の取得方法とページネーションのルールを再利用し、--status_categories UNSTARTED,STARTED を追加します。対象範囲：ユーザーがプロダクト／バージョンを指定した場合は、--assignees の代わりに --product_ids／--version_ids を使用します。ユーザーが明示的に「自分の」／自分のチケットと指定した場合は、--assignees <user_id> を使用します。どちらも指定されていない場合は、既定で自分のチケットを対象とし、その旨を伝えます。古いチケットが含まれる可能性があるため、--start_date 2000-01-01 --end_date <today> を使用します。

   • links のいずれかに /pull/ または /commit/ を含む url がある場合、そのチケットには「PR／コミットがある」とみなします。どちらか一方があれば該当します。未マージのオープンPRも、コミットへの参照のみのリンクと同様に、コード作業が進行中であることを示すためです。
   • 該当するチケットごとに、見つかったPR／コミットのリンク（それぞれがPRかコミットかも手順7と同じ方法で分類）と現在のステータスを報告し、チケットのステータスを本当に更新すべきか、ユーザーが判断できるようにします。

出力

• API のグループ分けに合わせて、製品ライン → 製品 → バージョンの順にまとめます。区別のない単一リストに再構成しないでください。ただし、ステップ 5 を実行した場合は、優先度順に並べた単一リストを表示します（各行に製品／バージョンも引き続き表示します）。
• 各チケットについて、ID、種類、優先度、ステータス、1 行のタイトルを表示します。
• 重大な問題は別のセクションに分け、製品ライン → 製品の順にまとめ、重大度／ステータスを表示します。
• 応答に summary が含まれていて、かつステップ 3 で対象範囲を絞り込んでいない場合は、冒頭に summary を記載します。summary は絞り込み前の応答全体を説明するため、絞り込んだ一覧と併記すると、実際に一覧表示されている内容と矛盾します。絞り込んだ場合は、代わりに絞り込まれた範囲の件数を示します（例：「UniFi Access 4.1.10 について、チケット 1 件、製品全体に関わる重大な問題 1 件」）。
• ステップ 3 で対象範囲を絞り込んだ場合は、結果を一覧表示する前に、何に絞り込んだかを明記します。
• 本当に担当チケットがない場合は、コメントのない空のセクションを返すのではなく、その旨を明確に伝えます。
• ルックアップ、ページ、バッチのいずれかを完了できなかった場合は、一覧の前に、確認できた内容と確認できなかった内容を伝えます（references/QUERY_RESILIENCE.md）。references/QUERY_RESILIENCE.md §5 の規則に従って回答を作成してください。CLI コマンド、内部フィールド名、推論の文章は含めないでください。
• ステップ 6 を実行した場合は、再オープンされたチケットごとに 1 件記載します（表示 ID、タイトル、再オープン日時、判明している場合は再オープンしたユーザー、理由または「記録なし」）。自分のチケットが再オープンされていない場合は、空の一覧を表示するのではなく、その旨を明記します。
• ステップ 7 を実行した場合は、取得した期間内のチケットごとに 1 件記載し、その PR／コミット／その他のリンクを示します（または「リポジトリへのリンクなし」）。日付フィールドに関する前提は、チケットごとではなく 1 回だけ記載します。
• ステップ 8 を実行した場合は、条件に該当するチケットごとに 1 件記載します。表示 ID、タイトル、現在のステータス、フラグの判定要因となった PR／コミットのリンクを示します。該当するチケットがない場合は、その旨を明記します。
• ステップ 5a を実行した場合は、履歴で確認できたステータス変更のみを一覧表示し、表示 ID、タイトル、変更前 → 変更後のステータス（判明している場合）、変更日時、新しいステータスが終端状態かどうかを記載します。変更のない親チケットは意図的に除外していることを明記します。

参照資料

• references/CAWPLAN_OPEN_API.md
• references/QUERY_RESILIENCE.md