mcpField
Q
qa-start

qa-start

github.com/petrkindlmannテスト・品質2221.1k 回インストール6 日前に更新
リポジトリ

qa-start について

新規プロジェクトやテスト基盤のないコードベースで、QAを順序立てて始めるスキルです。プロジェクトの背景、テスト戦略、初回計画を整え、最初のチェックを実行して証跡を保存します。

主な機能

  1. 01リポジトリを確認してプロジェクト情報を記録
  2. 02テスト戦略と計画を順番に作成
  3. 03成果物があれば該当手順を省略
  4. 04初回チェックを実行してレポートを保存
  5. 05次のE2EテストやCI作業を案内

活用シーン

  1. 01新規プロジェクトのQA基盤づくり
  2. 02放置または消失したテスト体制の再構築
  3. 03QA設定のない既存コードベースでの開始
  4. 04重要なユーザーフローの初回テスト作成

インストール

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

$npx skills add https://github.com/petrkindlmann/qa-skills --skill qa-start

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

詳細

QA の基盤がないプロジェクトで、QA を立ち上げるための順序立てられたランチャーです。リポジトリを調査し、利用可能なコンテキストを記録し、最初に確認する重要な動作を選んで、そのチェックを実行します。 判断を明確にするために `qa-project-context` → `test-strategy` → `test-planning` の順に使用し、計画成果物とともにテストの証拠と次に対処すべき具体的なギャップを提示します。

こんなときに使います

「QA はどこから始めればよいか」が分からず、QA の基盤がまだない場合は、いつでも qa-start を利用してください。

  • テストインフラがない新規プロジェクト。
  • QA の仕組みがまったく整っていない既存コードベースに参加するとき — コードは古くても、品質への取り組みが正式に定められていないケースです。この場合も qa-start を使います。qa-project-bootstrap は、すでにテストがあるチームに参加する場合に使います。
  • 放置されていた QA を立て直すとき — テストが削除され、カバレッジが低下し、戦略もないケースです。基盤から QA を再構築します。

コードベースに実際のテストスイートがすでにあり、チームに加わる QA エンジニアである場合は、代わりに qa-project-bootstrap を使ってください。

クイックルート

開始地点を選びましょう。成果物がすでにあるステップはスキップしてください。

状況開始地点
QA がまったくない(コンテキストファイル、戦略、計画がない)ステップ 1
.agents/qa-project-context.md がすでに記入済みステップ 1 をスキップし、test-strategy を実行(ステップ 2)
コンテキストファイルと戦略ドキュメントの両方があるステップ 1 と 2 をスキップし、test-planning を実行(ステップ 3)
3 つすべて完了 — 次は何をする?ステップ 3 の後
既存のテストがある既存チームに加わる QA エンジニアこのスキルではありません — qa-project-bootstrap を参照

ステップ 1:プロジェクトのコンテキストを記録する

スキル: qa-project-context

プロジェクトのルートに .agents/qa-project-context.md を作成します。このファイルには、技術スタック、テストフレームワーク、CI/CD パイプライン、環境、カバレッジ目標、リスク領域、チーム構成を記録します。後続のスキルはすべてこのファイルを読み込むため、同じ質問が繰り返されることはありません。

実行内容: qa-project-context を実行します。リポジトリと既存のタスクから調査を始め、その後ファイルを作成します。不明な判断事項は明示的に記録してください。次のアクションを変える未回答の項目だけを質問し、任意のコンテキストがなくても有用なチェックは続けてください。

完了条件: .agents/qa-project-context.md に、確認できた設定、利用可能なコマンド、現在のスコープ、未解決の判断事項が記録されています。チーム構成、目標、認証情報を捏造しないでください。

ステップ 2:テスト戦略を作成する

スキル: test-strategy

プロジェクトが品質にどう取り組むかを定めた戦略ドキュメントを作成します。これには、製品に適した単体テスト、統合テスト、E2E テストの割合を定めるテストピラミッド、開始・終了基準、ツールの選定、環境のカバレッジ、CI とリリースの品質ゲートが含まれます。

実行内容: ステップ 1 が完了したら test-strategy を実行します。コンテキストファイルを自動的に読み込むため、そこに記載済みの内容を再度質問することはありません。

完了条件: テストピラミッドの根拠、選定理由を含むツールの選択、CI とリリースの品質ゲート、テスト種別ごとの開始・終了基準を網羅した戦略ドキュメント(例:strategy.md)が作成されています。明確な判断をまとめた 1 ページのほうが、膨大なテンプレートより有用です。

ステップ 3:最初のテスト計画を作成する

スキル: test-planning

戦略を、最初のスプリントまたはリリースで実行可能な計画に落とし込みます。機能とテストケースを対応付け、工数を割り当て、最初にカバーする項目と後回しにする項目を決定します。

実行内容: ステップ 2 の後に test-planning を実行します。ステップ 2 の戦略とステップ 1 のコンテキストを使用します。プロンプトが表示されたら、機能の一覧またはスプリントのスコープを提示してください。

完了条件: 機能とテストケースの対応付け、カバレッジの優先順位、工数の見積もり、明確なスコープ境界が含まれたテスト計画(例:plan.md)が作成されています。これはチームが実行する計画成果物です。

最初のチェックを実行する

計画ドキュメントを作成する前に、リポジトリを確認してください。利用可能なコンテキストを使って通常の判断を行い、プロジェクトに見合った初期戦略と計画を立ててください。任意のコンテキストファイルがなくても、許可されたローカルテストの実行は妨げられません。

QA Skills のチェックアウト全体を利用できる場合は、次を実行してください。

node <qa-skills>/scripts/qa.mjs init --project <project> --wire-agent
node <qa-skills>/scripts/qa.mjs run --project <project> --goal "Check the critical user flow"

init は既存の設定を上書きせずにプロジェクト設定を作成します。今後のコーディングタスクに QA を組み込みたい場合は、--wire-agent を使用してください。既存の指示を保持しながら、プロジェクトの AGENTS.md に範囲を限定したワークフローを追加します。設定済みのプロジェクトでは init を省略してください。自動選択を有効にするには、ホストエージェントがそのプロジェクト指示を読み込む必要があります。

選択したドメインスキルを読み、そのワークフローを実行してください。テストがない場合は、観察された重要な動作に対する最初のテストを作成して実行してください。セットアップを合格として提示しないでください。依存関係によるブロックや未実行のフローも含め、実際の report.html と result.json を保存してください。スモークチェックに成功しても、確認できたのは実際に実行した動作だけです。ランナーの契約については、リポジトリの docs/QA-RUNNER.md を参照してください。

ステップ 3 の後

これで、コンテキスト、戦略、最初の計画という基盤ができました。次のアクションは使用しているスタックによって異なります。このランチャーは最終ステップではありません。

  • 最初の自動テスト: playwright-automation または cypress-automation を使い、最もリスクの高いフローを対象に最初の E2E テストを作成します。
  • CI への統合: ci-cd-integration を使い、すべてのプルリクエストでテストを実行できるようにします。
  • 品質の追跡: テストスイートの実行開始後に qa-metrics を使い、健全性の基準と経時的な測定方法を定義します。

qa-start と qa-project-bootstrap と qa-do

最もよくあるルーティングの混乱について、ここでまとめて説明します。

  • qa-start — QA が存在しない場合に、QA を立ち上げます。新規プロジェクト、または QA が削除され、再構築する場合に使います。手順:コンテキスト → 戦略 → 最初の計画。出力されるのは QA の基盤です。
  • qa-project-bootstrap — 既存のテストがあるチームに新たに参加する QA エンジニア向けの 30 日間の立ち上げプランです。チームのプロセス、オンボーディングのスケジュール、既存のテストスイートの監査を扱います。基盤を作成するためではなく、基盤ができた後に使用してください。
  • qa-do —「どのスキルを使えばよいか」という質問に対する最後の手段となるルーターです。適切なスキルが明確でない場合に使います。QA がないとすでに分かっている場合は、これを省略して qa-start を実行してください。

QA がない新規プロジェクトは、古いコードベースであっても、必ず qa-start を使います。qa-project-bootstrap は使いません。

手動コマンドとして固定する

Claude Code の /skills メニューから、いつでも再実行できます。

このスキルを手動専用コマンドとして固定するには、frontmatter に disable-model-invocation: true を追加するか、.claude/settings.local.json の skillOverrides で設定してください。

注意:一部の Claude Code ビルドでは、disable-model-invocation: true を設定すると手動のスラッシュコマンドも無効になります(参考:anthropics/claude-code#26251)。それでも /qa-start を手動で実行したい場合は、skillOverrides の状態を user-invocable-only に設定してください。

関連スキル

  • qa-project-context — ステップ 1。プロジェクトのセットアップ、技術スタック、品質目標を .agents/qa-project-context.md に記録します。
  • test-strategy — ステップ 2。テストのアプローチ、ピラミッド、ツール、品質ゲートを定義します。
  • test-planning — ステップ 3。機能とテストケースを対応付けた最初のテスト計画を作成します。
  • qa-project-bootstrap — 既存のテストがあるチームに QA エンジニアとして新たに参加する場合は、こちらを使ってください。このスキルは基盤を作成しますが、bootstrap はチームへのオンボーディングを行います。
  • qa-do — 適切なスキルが明確でない場合の最後の手段となるルーターです。QA がないとすでに分かっている場合は必要ありません。
  • playwright-automation / cypress-automation — 計画の後、最もリスクの高いフローを対象に最初の E2E テストを作成します。

コメント