qa

qa skill の概要

qa skill でできること

qa skill は、Web アプリを体系的に QA テストし、見つかった問題を修正してから再確認するための skill です。単なる「バグを探して」という一般的なプロンプトではなく、段階的な QA ワークフローに沿って検証し、証拠を残しながら、修正を原子単位で進めて再検証するところまで組み込まれているのが特長です。

どんな人に向いているか

qa skill は、回帰テスト、リリース可否の最終確認、本番に近い実アプリでの構造的なバグ発見が必要なときに向いています。すでに「機能は本来こう動くはず」と分かっていて、何がまだ壊れているのか、何が見た目だけの問題なのか、何がリリースを止めるのかをはっきりさせたい開発者、PM、AI オペレーターに適しています。

何が強みなのか

最大の価値は、判断の質が上がることです。qa skill は、テストの深さを段階的に変えられるほか、レポート先行・修正先行の両方のワークフローに対応し、重大度の分類も備えています。これにより、重大な回帰と優先度の低い微調整を切り分けやすくなり、単なるプロンプトよりもリリース確認に役立つ qa ガイドになります。特に、必要なのが推測ではなく証拠である場合に有効です。

qa skill の使い方

インストールして qa を起動する

npx skills add garrytan/gstack --skill qa でインストールします。その後、“qa this checkout flow”、“test this site for regressions”、“find bugs and fix the high-severity ones” のように、具体的なタスク文で起動します。この skill は QA らしい表現で動きやすい設計なので、レポートのみが欲しいのか、修正まで行ってほしいのかを明確に伝えるのが重要です。

入力は具体的に渡す

qa skill は、アプリの URL、何が変更されたか、対象のブラウザやデバイスがあるならそれも、そして希望するテストの深さを渡すと最もよく機能します。弱い入力は「アプリをテストして」です。より良い入力は、“Run Standard qa on the new profile settings flow at https://…, focus on save/cancel, validation, back navigation, and mobile layout, and only fix critical/high issues.” のような形です。これなら、対象範囲と重大度の境界が明確になります。

まず確認すべきファイル

qa の使い方を理解するには、まず SKILL.md を読み、次に references/issue-taxonomy.md と templates/qa-report-template.md を確認してください。SKILL.md にはワークフローとルーティングの説明があり、taxonomy では見つけた問題の分類方法が分かります。report template は、期待できる出力の形を示しています。自分の repo に qa skill を合わせ込む場合も、これらのファイルがインストール時の挙動を理解する最短ルートです。

実践的なワークフローのコツ

qa はループとして扱うのがコツです。テストを実行し、問題を分類し、原子単位で修正し、再検証します。回帰テストをしたいなら、機能名、ユーザーパス、直近の変更点を伝えると、skill が壊れやすい箇所を優先しやすくなります。より広い範囲を見たいなら Standard か Exhaustive を指定し、速度を優先したいなら Quick を指定したうえで、見た目だけの問題は無視してよいと伝えてください。最も大きな品質向上は、最初の一回目の前にスコープを絞ることから生まれます。

qa skill の FAQ

qa はバグ発見だけのためのものですか？

いいえ。qa skill はバグ発見だけでなく、機能がリリース可能かどうかの確認や、何をテストしたかを構造化して報告する用途にも使えます。Regression Testing のための本格的な qa ガイドが必要なら、範囲の広い「アプリをレビューして」というプロンプトよりもこちらの方が役立ちます。

qa は通常のプロンプトとどう違いますか？

通常のプロンプトは、たいてい一度サイトを確認するよう依頼するだけです。qa skill はそこにワークフローの規律を加えます。重大度の段階、レポート構成、修正して再テストする挙動、どこからが blocker かの扱いがより明確です。その結果、「これ、本当に動くのか？」という問いに対して、やり取りの往復が減ります。

初心者でも使えますか？

はい、機能と期待する結果を説明できるなら使えます。初心者ほど、ページ、フロー、デバイス、許容できる重大度を具体的に書くと成果が出やすくなります。スコープを定義できなくても実行自体はできますが、その場合は見つかった内容の実用性が下がることがあります。

どんなときに qa を使うべきではありませんか？

コピーの添削、アーキテクチャレビュー、一般的なプロダクト批評だけが目的なら、qa は使わないでください。実行可能な UI がない、または実アプリに対して挙動を確認できないタスクにも向きません。そうした場合は、別の prompt や skill の方が効率的です。

qa skill をより良く使うには

テストの境界条件をもっと明確にする

qa skill は、何が変わったのか、何を最も重視するのかを伝えるほど精度が上がります。対象の route、ユーザーロール、デバイス種別、既知のリスク領域を含めてください。Regression Testing 用の qa では、以前は通っていた正確な workflow を書いておくと、agent が期待動作と現在の build を比較しやすくなります。

適切な tier を指定する

ブロッカーだけ見たいなら Quick、通常のリリース確認なら Standard、見た目や UX の問題まで気にするなら Exhaustive を使ってください。tier を指定しないと、実際のリリースリスクに対して qa skill のチェックが過剰にも不足にもなり得ます。意図に合った tier を選ぶことは、時間の節約にも、出力への信頼にもつながります。

証拠を取りやすいコンテキストを渡す

アプリが認証、投入済みデータ、feature flags、staging 環境に依存するなら、最初にその条件を書いてください。qa skill は、問題をきれいに再現し、正確な手順で報告できるときに最も強くなります。また、「完了」の定義も伝えてください。たとえば、重大な問題がないこと、console errors がないこと、あるいは現在の branch での修正だけでよいこと、などです。

最初の結果を踏まえて反復する

最初の report のあとで、変更した箇所だけを再テストして、何が改善したかを要約するよう qa skill に依頼してください。指摘が広すぎるならスコープを絞り、浅すぎるなら一つの path を深掘りするよう求めます。qa の使い方を最短で改善する方法は、曖昧なレビュー依頼を、成功条件を明示した再現可能なテスト指示に変えることです。