qa

QA

機能、バグ修正、デプロイの機能検証を行います。テストシナリオを実行し、証拠を記録して、正常に動作するかどうかを確認してください。

作業上の合意事項

ユーザー向けの質問はすべて AskUserQuestion を通じて行います（Autopilot でない場合）。規約については desplega:ask-user を参照してください。

ファイルレビューはデフォルトで有効です。準備ができたら QA レポートに対して実行してください（Autopilot の場合のみ省略します）。

所有権：QA ドキュメントはプラン内ではなく、ここに置く

QA テストケースは、プラン内に直接記載するのではなく、QA ドキュメント（thoughts/<username|shared>/qa/YYYY-MM-DD-<feature>.md）に記載します。プランに ### QA Spec (optional): ブロックがある場合、そのブロックにはこのスキルで作成する QA ドキュメントへのリンクを記載します。

このスキルは、複数の範囲にまたがる QA や証拠が多く必要な QA 専用です。フェーズごとの定例チェックには使用しません。フェーズごとの定例的なエージェント検証は、プラン内の #### Automated QA: 項目に記載し、phase-running で実行します。次の場合にこのスキルを使用してください。

• QA 作業が複数のフェーズ、または機能全体にまたがる
• スクリーンショット、録画、ログなどの証拠を長期保存する必要がある
• 合格／不合格／ブロックの正式な判定が必要である

呼び出し経路：

• Planning の Step 3（「QA docs の生成」）では、フェーズの QA に個別のドキュメントが必要な場合、引き継ぎ前にこのスキルを呼び出します。
• Implementing / phase-running では、フェーズ完了時に、そのフェーズから QA Doc: <path> が報告された場合、このスキルを呼び出します。
• ユーザーからの直接呼び出し（/qa）では、プランにリンクされていない独立したドキュメントを作成します。

QA の実施方法

Autopilot でない場合は、開始時に一度だけ質問します。

質問	選択肢
「テストケースをどのように実行しますか？」	1. 利用可能な場合はブラウザー自動化（agent-browser）、2. 手順に沿った手動テスト、3. 混合：可能なものは自動化し、残りは手動で実施

agent-browser の利用可否に関する注意：command -v agent-browser を実行してください。これは CDP 経由で操作するヘッドレス Chromium 用の agent-browser npm CLI（vercel-labs）です。また、プロジェクトの CLAUDE.md で別のテストツールが指定されていないか確認してください。agent-browser が利用できず、代替ツールの指定もない場合は、手動テストをデフォルトとします。ユーザーが指定しない限り、qa-use は使用しないでください。

使用するタイミング

このスキルは次の場合に有効になります。

• ユーザーが /qa コマンドを呼び出したとき
• 別のスキルが desplega:qa を参照したとき
• ユーザーが機能のテスト、検証、QA を依頼したとき
• 実装スキルで QA 仕様のあるフェーズに遭遇したとき

自律性モード

QA の開始時に、自律性モードに応じて対話のレベルを調整します。

モード	動作
Autopilot	すべてのテストケースを実行し、証拠を記録して、最後に概要を提示します
Critical（デフォルト）	テストケースの設計について質問し、結果をレビュー用に提示します
Verbose	各テストケースを順に確認し、実行前に承認を求めます

自律性モードは呼び出し元のコマンドから渡されます。指定がない場合は Critical をデフォルトとします。

プロセスの手順

Step 1: コンテキストと範囲

QA 仕様の出所を判断します。

プラン主導（planning/implementing/phase-running から呼び出された場合） → プランのパスとフェーズ参照が渡されます。該当フェーズを読み、その Overview に記載された成果物のテストケースを設計し、プランの QA Spec ブロックから参照する QA ドキュメントを作成します。

独立した QA 仕様ドキュメントが提供された場合 → その仕様書を読み、QA セッションの基礎として使用します。

ユーザーから直接呼び出され、参照元がない場合 → ユーザーとともにテストケースを一から作成します。AskUserQuestion を使用して、以下を確認します。

質問	選択肢
「何を検証しますか？機能について説明するか、関連情報を提供してください。」	［自由記述］

いずれの場合も、cc-plugin/base/skills/qa/template.md をもとに QA ドキュメントを作成し、thoughts/<username|shared>/qa/YYYY-MM-DD-<topic>.md に保存します。ユーザー名がわかる場合はそれを使用し、不明な場合は thoughts/shared/qa/ を使用します。

プラン主導の呼び出しの場合：ドキュメントの作成後、該当フェーズのプラン内にある ### QA Spec (optional): ブロックを更新し、ドキュメントのパスを記載します。プラン内にシナリオを直接記載しないでください。

ステップ 2：テストケースの設計

以下を網羅するテストケースを定義します。

• 正常系 — 主要なシナリオが意図どおりに動作する
• エッジケース — 境界条件、空の入力、大きな入力
• エラーシナリオ — 無効な入力、権限エラー、ネットワークエラー

プランを元にする場合：各フェーズの QA 仕様をテストケース一覧にまとめます。探索的テストケースも追加します。

別の仕様書を元にする場合：その仕様書のシナリオを出発点として、探索的テストケースを追加します。

ブラウザー自動化が選択され、agent-browser が利用可能な場合：各テストケースの agent-browser 操作手順（open、snapshot、refs の操作、screenshot）を設計します。

すべてのテストケースを QA ドキュメントの ## Test Cases セクションに記載します。

ステップ 3：テストを実行する

ブラウザー自動化（agent-browser）の場合：agent-browser スキルがインストールされている場合（swarm がシードするもの）、その手順に従います。それ以外の場合：

1. セッションごとに一度、バージョンに対応したガイドを agent-browser skills get core で読み込んでから（記憶を頼りにフラグを推測しないでください）、agent-browser open <url> を実行します
2. agent-browser snapshot -i でページの状態と @eN refs を確認します
3. refs を操作し（click @eN、fill @eN "text"、type、press）、ナビゲーションまたは状態変更のたびに snapshot を再取得します。refs は、それを生成した snapshot に対してのみ有効です
4. 証跡として agent-browser screenshot /tmp/<name>.png を実行し、その後 agent-browser close を実行します
5. スクリーンショットをマシンの外部と共有するには、agent-fs に agent-fs write <path> --file /tmp/<name>.png -m "<what it shows>" でアップロードします（バイナリーセーフです。--content は PNG を破損させます）。元ファイルとして agent-fs に保持し、PR または GitHub コメントには GitHub ユーザー添付ファイル（github-attach スキル）として埋め込みます：![caption](https://github.com/user-attachments/assets/<uuid>)。Slack または Linear で共有する場合は agent-fs share-create <path> を使用します。agent-fs が設定されていない場合は、ローカルパスを報告し、アップロードをスキップしたことを伝えます

手動テストの場合：

1. 各テストケースの手順をユーザーに提示します
2. 実行を案内します
3. 結果の収集には AskUserQuestion を使用します：

質問	選択肢
「TC-N：［テストケース名］。合格しましたか？」	1. 合格、2. 不合格 — ［発生した内容を説明］、3. ブロック — ［ブロック要因を説明］、4. スキップ

CLI 検証の場合：

1. CLI コマンドを直接実行します
2. 出力を期待される結果と比較します
3. 合否を自動的に記録します

任意のサブスキル： CLI テストケースで、後から同じ複数ステップの検証を再実行する必要があり（回帰テスト、デプロイ後のスモークテスト、複数環境での検証）、既存のスクリプトで対応できない場合は、desplega:script-builder をインラインで呼び出します。生成されたスクリプトは、PASS/FAIL と /tmp ログの規約に従ってプロジェクトの scripts/ ディレクトリにコミットされます。この QA セッションでは現在の実行に使用し、今後の QA／検証セッションでは、CLAUDE.md に自動追加された <important if> ブロックによって見つけられます。

各テストケースについて、実際の結果と合否ステータスを記録します。

ステップ 4：証跡を収集する

QA レポート用の証跡を収集します。

• スクリーンショット：agent-browser screenshot で取得（agent-fs に保持し、PR には GitHub ユーザー添付ファイルを、その他の場所には share-create のリンクを使用）、またはユーザーから提供されたもの
• 動画：セッション録画の URL（Loom など）
• ログ：コンソール出力、エラーメッセージ、関連するログ行
• 外部リンク：Sentry のイシュー、CI/CD の実行結果、Grafana ダッシュボード、PR の URL

すべての証跡を QA ドキュメントの ## Evidence セクションに追加します。

ステップ 5：結果を記録する

QA ドキュメントを次の内容で更新します。

• 各テストケースの実際の結果
• テストケースごとの合格／不合格／ブロック／スキップのステータス
• 関連するテストケースにインラインで記載した証跡リンク
• 見つかった問題を、重大度タグ（critical／major／minor）とともに ## Issues Found セクションに記載

ステップ 6：判定

結果を集約して総合判定を行います。

判定	条件
PASS	すべてのテストケースに合格し、重大または主要な問題がない
FAIL	いずれかのテストケースに失敗した、または重大・主要な問題が見つかった
BLOCKED	環境または依存関係の問題によりテストを完了できない

QA ドキュメントの ## Verdict セクションに、1～2 文の要約を記載します。frontmatter の status フィールドを判定に合わせて更新します（pass/fail/blocked）。

ステップ 7：QA ナレッジの保存

プロジェクトの CLAUDE.md または agents.md に、このプロジェクトでの QA の実施方法が記載されていない場合は、以下の内容を説明する QA セクションを追加するか、ユーザーに確認します。

• 使用したテスト方法（手動、ブラウザー自動化、CLI）
• 使用したツール（agent-browser、Playwright など）
• 見つかった一般的なテストパターン

以下を使用して AskUserQuestion を行います。

質問	選択肢
"This project doesn't have documented QA practices. Would you like me to add a QA section to CLAUDE.md?"	1. はい、QA のドキュメントを追加する、2. いいえ、スキップする

また、複数の QA セッションを通じて有用なパターンが見つかった場合は、メモリにも保存します。

レビューとの連携

ファイルレビューはデフォルトで有効です（Autopilot の場合を除く）。

• QA レポートの作成後、インラインで人間のコメントを付けるために /file-review:file-review <qa-report-path> を呼び出します
• file-review:process-review スキルでフィードバックに対応します

学びの記録

任意のサブスキル： このワークフローで重要な知見、パターン、注意点、判断が得られた場合は、desplega:learning を使って /learning capture で記録することを検討します。今後のセッションでほかの人に役立つ学びに焦点を当てます。

ワークフローの引き継ぎ

QA レポートの作成後、以下を使用して AskUserQuestion を行います。

質問	選択肢
"QA complete. What's next?"	1. QA 後の検証を実行する（→ /verify-plan）、2. QA レポートをレビューする（→ /review）、3. 完了

回答に応じて、以下を行います。

• 検証：desplega:verifying スキルを呼び出します
• レビュー：QA ドキュメントに対して desplega:reviewing スキルを呼び出します
• 完了：QA レポートを確定します