mcpField
C
cawplan-qa-commit

cawplan-qa-commit

github.com/cawcutテスト・品質1104 回インストール2 日前に更新
リポジトリ

cawplan-qa-commit について

QA 日報の収集、製品とチケットの割り当て、内容確認、アップロードを案内するワークフロースキルです。単日処理と、月内の未提出日を調べて個別に補完する処理に対応します。

主な機能

  1. 01QA セッションの収集とユーザー入力の統合
  2. 02確認ページでの製品・チケット割り当て
  3. 03レポート内容とデータ品質の確認
  4. 04月内の未提出日の検索と個別アップロード

活用シーン

  1. 011 日分の QA 日報を作成してアップロード
  2. 02指定月の未提出 QA 日報を補完

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/cawcut/skill-cawplan --skill cawplan-qa-commit

インストール後、Claude Code で/cawplan-qa-commitを入力して読み込まれたか確認します。

詳細

CawPlan QA Commit

初期設定

cawplan skill check

ワークフロー

このスキルでは、次の2つのワークフローをサポートしています。

  • 単日ワークフロー： 収集 → 割り当て → レビュー → アップロード
  • 月次の不足分ワークフロー： クラウド上でその月のQA日報の不足日を照会 → 不足日のみを収集、割り当て、レビュー、アップロード

cawplan session collect --mode qa はHTML Review Human Inputイベントを自動的にマージします。ローカルのoutboxを読み取ったり、イベントを手動で追加・要約したりしないでください。収集時の警告は、既存のData quality notesを通じて表示してください。

このスキルの対象外（独自の判断で実行しないでください）：

  • cawplan session backfill — このコマンドが確認するのはQAではなく、コーディングの日報（ai-session-usage）です。代わりにcawplan session qa-backfill --dry-runを使用してください。
  • cawplan session qa-backfillを--dry-runなしで実行すること — CLIでは一括アップロードがまだ実装されていません。qa-backfillでは絶対に--dry-runを省略しないでください。
  • チケットの進捗の書き戻し（cawplan tickets update --progress_comment）。
  • cawplan session assign --web（git-repoマッピングを使用するコーディングフロー）。
  • 単日のアップロード後に実行する当月分の自動バックフィル（Step 7–11に相当する機能はありません）。

サポートされている単日の引数：

  • 日付なし、today → 今日の日付
  • yesterday、yestoday → 昨日の日付（よくあるタイプミスとしてyestodayも受け付けます）
  • YYYY-MM-DD → 指定した日付

サポートされている月次の不足分の引数：

  • last month → 前の暦月
  • YYYY-MM → 指定した暦月
  • 特定の月の不足しているQA日報をアップロード・補完するよう求める自然言語の依頼 → その暦月

例：

  • /cawplan-qa-commit
  • /cawplan-qa-commit yesterday
  • /cawplan-qa-commit 2026-08-20
  • /cawplan-qa-commit last month
  • /cawplan-qa-commit 2026-08

ユーザーが単日の引数を指定した場合は、Step 1の前に日付を確定し、以下の単日ワークフローに従ってください。ユーザーが月次の不足分を指定した場合は、単日ワークフローをスキップして、以下の月次の不足分ワークフローに従ってください。ユーザーがサポートされていない引数を指定した場合は、推測せず、有効な日付または月を尋ねてください。

ユーザーが1つの依頼でQAとコーディングの両方の日報に言及した場合は、どちらを希望するか（QAのみ／コーディングのみ／両方）を1回だけ尋ねてください。デフォルトで両方のスキルを実行しないでください。

アップロードの前に、必ずレビューの概要を収集して提示してください。ユーザーがレビューを確認した後（または、割り当ての時点ですでにレビュー内容がインラインで表示されている場合はその直後）にアップロードしてください。

権限の最小化

  • 論理的なフェーズごとに、細かなコマンドを多数実行するのではなく、1つのシェルブロックとして実行してください。
  • 収集フェーズでCursorエージェントのシェルツールを使う場合は、シェルブロック全体に対して一度だけフルネットワークアクセスを要求してください（required_permissions: ["full_network"]）。収集時にcursor.comのCursor Dashboard APIが呼び出されることがあるためです。
  • 生成したすべてのqa-daily-*.jsonファイルは、現在のリポジトリではなくシステムの一時ディレクトリに保存してください。これにより、リポジトリへの書き込み許可を求めずに済み、生成されたレポートファイルが作業ツリーに残りません。
  • 収集、割り当て、レビュー、アップロードには、同じワークフロー用の一時ディレクトリを再利用してください。

収集の前に、ワークフロー用のQA一時ディレクトリを1つ作成してください（--outputを省略した場合のCLIのcollect --mode qaのデフォルトに一致します）。

qa_daily_dir="${TMPDIR:-/tmp}/cawplan-qa-daily"
mkdir -p "$qa_daily_dir"
daily_file="$qa_daily_dir/qa-daily-<YYYY-MM-DD>.json"

以降の収集、割り当て、レビュー、アップロードの各ステップでは、qa_daily_dir配下の絶対パスを使用してください。ユーザーが出力先を明示的に指定した場合を除き、生成したQA日報のJSONを現在の作業ディレクトリに書き込まないでください。

collectは各日報ファイルの隣にqa-daily-<YYYY-MM-DD>.excluded.jsonも書き込みます。qa-assignはこのサイドカーファイルを使って補足対象のリストを読み取ります。除外されたセッションの情報を意図的に破棄する場合を除き、サイドカーファイルを手動で編集または削除しないでください。

月次の欠落レポートのワークフロー

ユーザーから、特定の月の不足している QA レポートのアップロードや補完を依頼された場合、または last month や YYYY-MM などの月を指定された場合は、このワークフローを使用します。

ステップ M1 — 月の期間を決定します：

  • last month の場合は、前の暦月の初日から末日までを使用します。
  • 過去の YYYY-MM の場合は、その月の初日から末日までを使用します。
  • 現在の YYYY-MM の場合は、その月の初日から今日までを使用します。
  • 指定された月以外の日付は含めないでください。

ステップ M2 — クラウド上の欠落日を照会します：

cawplan session qa-backfill --from <YYYY-MM-01> --to <YYYY-MM-last-or-today> --dry-run

このドライランでは missing_dates のみを使用してください。すでにアップロード済みの日付を収集したり、上書きしたりしないでください。missing_dates が空の場合は、指定された月に不足している QA レポートはないことをユーザーに伝え、終了します。

missing_dates はカレンダー上の空白期間のリストです（週末と祝日は除外されません）。このリストをユーザーに提示してください。ユーザーは、作業しなかった日付をスキップできます。

ステップ M3 — 並列数を制限して不足日分を収集します：

collect_concurrency="${CAWPLAN_COLLECT_CONCURRENCY:-5}"
i=0
for date in <date1> <date2> ...; do
  cawplan session collect --date $date --mode qa --output "$qa_daily_dir/qa-daily-$date.json" &
  i=$((i + 1))
  if [ $((i % collect_concurrency)) -eq 0 ]; then
    wait
  fi
done
wait

収集のたびに Cursor Dashboard API が呼び出される可能性があるため、並列数を制限してください。デフォルトの並列数は 5 です。ネットワークまたは Cursor API が不安定な場合にのみ、CAWPLAN_COLLECT_CONCURRENCY の値を下げてください。

ステップ M4 — プロダクト／チケットの割り当て：

新たに収集した不足日分のファイルごとに、日付順に プロダクト／チケットの割り当て を実行します。一度に実行する qa-assign は 1 つにしてください。次の日付の処理を始める前に、各割り当てコマンドの完了を待ってください（QA の割り当ては現在、コマンド 1 回につきファイル 1 つに対応しています）。

ステップ M5 — 確認：

アップロードする不足日ごとに、アップロード前に レビュー内容の契約 で説明されているレビュー内容をすべて提示してください。統計テーブルだけを表示しないでください。

ステップ M6 — 不足分のレポートをアップロードします：

新たに収集した不足日分のファイルを、日付順に 1 つずつアップロードします：

cawplan session qa-upload --file "$qa_daily_dir/qa-daily-<YYYY-MM-DD>.json"

アップロード後、指定された月、アップロードした日付、アップロードした各レポートの QA セッション数、および各サーバーのレスポンスコードを報告してください。月をまたがないでください。

1 日のワークフロー

ステップ 1 — 収集：

daily_file="$qa_daily_dir/qa-daily-<YYYY-MM-DD>.json"
cawplan session collect --date <YYYY-MM-DD> --mode qa --output "$daily_file"

ステップ 2 — 製品／チケットの割り当て：

収集したファイルから QA 割り当ての確認ページを開きます（git-project 列はなく、製品とチケットのみです）。

cawplan session qa-assign --file "$daily_file"

qa-assign はバックグラウンド／ノンブロッキングのシェルタスクとして実行してください（例：Bash の run_in_background: true）。通常のフォアグラウンド呼び出しとして実行してはいけません。このコマンドはブラウザーでの入力を最大 10 分間待機するため、ユーザーが操作を終える前に待機中のフォアグラウンド呼び出しがシェルのジョブ制御によって一時停止されると、ポートを保持したままのプロセスが残ります。

ユーザーがブラウザーで操作を終えるまで、実行中の qa-assign コマンドは必ず 1 つだけにしてください。ユーザーが Save assignments をクリックするか、Close をクリックするか、ターミナルで Ctrl+C を押すか、ローカルの割り当てサーバーが 10 分でタイムアウトすると、コマンドは終了します。

同じ daily_file に対する前の割り当てコマンドがまだ実行中の場合は、長時間待機していても qa-assign を再実行しないでください。長時間の待機は、コマンドの失敗ではなく、ページがユーザーの操作を待っていることを意味します。進捗を伝える必要がある場合は、すでに開いている割り当てページで保存または閉じる操作を行うようユーザーに伝え、その後、既存のコマンドが終了またはタイムアウトするまで待ってから続行してください。

割り当てページを読み込めない場合や、前の実行が停止しているように見える場合は、コマンドの失敗と判断する前に、停止したプロセスがないか確認してください（ps aux | grep "session qa-assign"。STAT が T の場合は一時停止されており、ページを配信していません）。プロセスが実際に停止している場合にのみ終了させて再起動し、単に待機中の場合は再起動しないでください。

このページでは、ユーザーが次の操作を行えます。

  • 収集された QA セッションを確認する（セッション ID、エージェント、スキルレイヤー — 空の場合があります、テストポイント数、要件）
  • 右端の Action 列で Ignore / Undo を使用する。無視したセッションは、灰色の行と灰色のステータスドットでそのまま表示されます。製品／チケットのコントロールは値を消去せずに無効になります。変更が保存されるのは Save assignments をクリックした後のみで、対象はこの日次ファイルのみです。再収集するとリセットされます。元のセッションデータは保持されます。review_stats のない古い日次ファイルでは、Ignore を使用する前に再収集が必要です。古いファイルをアップロードせず、そのエラーをユーザーに提示してください。
  • アクティブなセッションごとに製品を 1 つ選択する（ドロップダウン）
  • チケットの表示 ID を編集する
  • 任意で、コミットのみ／空の除外リストからセッションを追加する（セッション ID を手入力する必要はありません）

ステップ 3 — チケットのコンテキスト確認：

報告時にチケット ID をユーザーに手動で提示するよう求めないでください。cawplan session collect --mode qa は、CawPlan の課題 URL や表示 ID を含め、セッションの human_inputs から明示的なチケット参照を解析します。割り当てページでは、ユーザーが保存すると表示 ID が内部の ticket_ids に解決されます。

$daily_file を確認する際は、assign 後にすでに存在する sessions[].ticket_ids と sessions[].ticket_display_ids に言及してください。チケットのコンテキストは、明示的なユーザー入力の参照、または割り当てページでの編集に基づく必要があります。キーワード検索でチケットを探したり、チケットを推測したりしないでください。

ステップ 4 — レビュー：

アップロード前に、レビュー内容の要件で説明されているレビュー全体を提示してください。統計テーブルだけを表示してはいけません。

ステップ 5 — アップロード：

cawplan session qa-upload --file "$daily_file"

成功時に返される report_id UUID を含め、サーバーの応答をそのまま出力してください。このアップロード後に、当月の欠落日付クエリや追加のバックフィルを実行してはいけません。

レビュー内容の契約

ignored: true のセッションは取り消しに備えてローカルに保持されますが、人間の入力や統計情報も含め、アップロード対象からは除外されます。以下のレビューでは、ignored: true が設定されていないセッションと、それらの人間の入力のみを使用し、無視されたセッション数は別途記載してください。review_stats はローカルの集計用メタデータであり、QA作業の内容ではありません。有効なセッションが残っていない場合は、アップロードをスキップすることを報告してください。既存のクラウドレポートをアップロードしたり変更したりしてはいけません。

アップロード前に、次の内容を含めてください。

  • 基本情報：日付、作成者、QAセッションの合計数、エージェント、合計コスト。
  • 全体の概要：セッション全体で行われたQA作業（検証した要件、作成したテストポイント／テストケース、対応したチケット）について、2〜4文で記述します。QAペイロードにはトップレベルのsummaryフィールドがないため、セッションとhuman_inputs[].contentから導き出してください。
  • セッションレビュー：重要な各セッションについて、session_title、エージェント、存在する場合はdisplay_time_range、コスト、skill_layers、要件／テストポイント／テストケースの件数、product_id、チケットの表示IDを含めてください。実施した作業について、タイトルと件数だけを列挙するのではなく、1〜2文で説明してください。
  • 割り当てに関する注記：補足リストから追加されたセッションがあれば記載し、すべての有効なセッションにプロダクトが割り当てられていることを確認してください。
  • データ品質に関する注記：skill_layersが空のセッション数、collectの実行時に出力された除外セッション（commitのみ、または空のみ。該当する場合）、割り当てページでユーザーがセッションを補足したかどうか、collectのstderr警告、コストがないセッション、割り当てページで未解決のチケット表示IDを記載してください。

human_inputsを、categoryやtopicなどのコーディング専用フィールドを使って要約しないでください。QAペイロードにはこれらのフィールドは含まれていません。

プロダクト／チケットの割り当て

  • ウェブでの確認には必ずcawplan session qa-assign --file <absolute-qa-daily-file>を使用してください。再収集を行うcollect --mode qa --assignや、gitプロジェクトのマッピングを使うコーディングフローのcawplan session assign --webは使用しないでください。
  • プロダクトの選択には、コーディングインサイトと同じCawPlanプロダクトカタログを使用しますが、gitプロジェクトとの紐付けは行いません。プロダクトピッカー（cawplan session productsと同じ情報源）では、controls配列にcoding-insightsが含まれていないプロダクトは除外されます。ユーザーが希望するプロダクトが見つからない場合は、コーディングインサイトが有効になっていないことを伝えてください。代わりのプロダクトを推測したり、JSONのproduct_idを手動で編集したりしてはいけません。
  • 1つのセッションに割り当てられるプロダクトは1つだけです。割り当てページでは、すべての有効なセッションにリストからプロダクトが選択されるまで、保存できません。
  • 保存時、割り当てページはCloudを介してチケット表示IDを内部のticket_idsに解決します。解決できない表示IDがあると、エラーが発生して保存に失敗します。古いファイルをアップロードするのではなく、そのエラーをユーザーに伝えてください。

ルール

  • このスキルで実行するすべての collect コマンドには、--mode qa を必ず含めてください。
  • セッションデータを捏造しないでください。ローカルエージェントが生成した内容と、課題ページでユーザーが明示的に編集した内容のみを含めてください。
  • QA の日報に、コーディング用の一時パス（cawplan-ai-daily / ai-daily-*.json）を使用しないでください。
  • --file / daily_file を使用する場合、JSON に schema: "qa-session.1"、author、date を含めてください。
  • QA スキーマで許可されている生の human_inputs フィールド（content、assistant_message、session_id、start_time、end_time）を保持してください。category、topic、その他のコーディング専用キーは決して追加しないでください。
  • JSON ファイル内の生の human_inputs を、要約した内容に置き換えないでください。要約はアップロード前の対話でのレビューにのみ使用してください。
  • collect と課題ページで特定できる範囲を超えて、キーワード検索をしたり、チケット、製品、要件を推測したりしないでください。
  • このワークフローでは、cawplan session report、cawplan session backfill、cawplan session assign --web を使用しないでください。
  • cawplan session qa-backfill は、欠落の検出に限り --dry-run と併用してください。欠落している日付のアップロードには、日付ごとに collect → qa-assign → レビュー → qa-upload の順で実行してください。--dry-run なしで qa-backfill を呼び出さないでください。
  • 1 日分をアップロードした後に、当月分の自動バックフィルを実行しないでください。
  • ユーザーが QA やテストに言及せず、「提交日报」とだけ言った場合は、このスキルを使用しないでください。代わりに cawplan-coding-commit に振り分けてください。

確認

アップロード後、次の内容を表示してください。

  • サーバーが受け付けた日報の日付。
  • アップロードしたファイルに含まれる QA セッション数。
  • サーバーが report_id を返した場合は、その値。
  • Code フィールド（SUCCESS / FAILURE）。
  • FAILURE の場合は、エラーメッセージをそのまま表示してください。

参考資料

  • references/CAWPLAN_OPEN_API.md

コメント

Markdown 対応