browse-qa
Webやアプリの機能をチケット、URL、受け入れ基準、または自然言語での説明からQAし、リグレッション対応のための再利用可能なブラウズフローを生成します。実際のブラウザまたはシミュレーター操作には`browse`スキルを使用し、QAループをシナリオ、エビデンス、レポート品質に集中させます。
description の原文を見る
QA a web or app feature from a ticket, URL, acceptance criteria, or plain-language description, then generate reusable browse flows for regression coverage. Uses the `browse` skill for the actual browser or simulator interaction and keeps the QA loop focused on scenarios, evidence, and report quality.
SKILL.md 本文
譲歩できないルール：
- 受け取った仕様を明示的なシナリオに変換してからテストします。
- 曖昧なターゲットやプラットフォームについては、実行前に確認します。
- 実際のブラウザまたはシミュレータの操作には
browseスキルを使用します。 - 失敗した重要なシナリオごとにエビデンスをキャプチャします。
- リグレッション検証に価値がある、きれいにスコープされたフローのみを保存します。 </EXTREMELY-IMPORTANT>
browse-qa
入力
$request: チケット、URL、アプリターゲット、受け入れ基準、または自然言語のQA依頼
目標
信頼性のあるQA実行を実現し、以下を含みます：
- 曖昧な依頼を明示的なシナリオに変換する
- それらのシナリオを実際のターゲットに対して実行する
- 成功と失敗のエビデンスをキャプチャする
- 必要に応じて再利用可能なブラウズフローを保存する
- ユーザーが対応できるきれいなQAレポートを返す
ステップ 0: ターゲットと仕様を解決する
以下を確認します：
- テスト対象の機能
- プラットフォーム：ウェブ、iOSシミュレータ、Androidエミュレータ、またはmacOSアプリ
- ターゲットURL、ビルドアーティファクト、またはアプリ識別子
- 受け入れ基準または期待される結果
ターゲットまたはプラットフォームが曖昧な場合は、テスト前に確認してください。
成功基準: QAターゲットと受け入れ基準が明示的になっている。
ステップ 1: シナリオリストを構築する
依頼を以下に分割します：
- ハッピーパス
- 検証またはエラーパス
- エッジケース
- 記載された受け入れ基準の後で試す価値のある探索的なプローブ
ユーザーが広範なQA検証を依頼した場合を除き、計画を1セッション内で実行できる十分に小さい規模に保ちます。
成功基準: 期待される結果を含む具体的なシナリオリストがある。
ステップ 2: browse スキルで実行する
以下に Skill を使用して browse を呼び出します：
- ナビゲーション
- ページの安定化
- インタラクティブ要素の発見
- クリック、入力、送信
- スクリーンショット、コンソールログ、ネットワーク検査
ルール：
- 意図的な隔離を除き、1つの論理的なユーザージャーニーには同じブラウズセッションを保持する
- CAPTCHA、MFA、またはOAuthウォールなどの実際のブロッカーの場合のみ、ヘッドモードまたはハンドオフモードを使用する
- スクリーンショットとフローアーティファクトをブラウズセッションディレクトリ下に保存する
成功基準: 各シナリオが実際のターゲットに対して実行され、合格/不合格を判定するのに十分なエビデンスがある。
ステップ 3: 再利用可能なリグレッションフローを記録する
シナリオが安定していて再実行する価値がある場合：
- フローを記録する
- 関連のないユーザージャーニーを別のフローファイルに分割する
- 保存された各フローに説明的な名前を付ける
ノイズが多い、または半手動の記録をリグレッションアーティファクトとして保存しないでください。
成功基準: 保存されたフローが独立して再実行可能であり、明確なシナリオにマップされている。
ステップ 4: 結果をレポートする
各シナリオについて、以下を記録します：
- 期待される結果
- 実際の結果
- 成功/失敗
- スクリーンショットパス、コンソールエラー、またはネットワーク症状などのエビデンス
また、以下もレポートします：
- 探索的な発見
- 作成されたリグレッションフローファイル
- 検証を妨げたブロッカー
成功基準: 別のエンジニアがセッション全体を再実行する必要なく、QAの結果を理解できる。
ガードレール
- ブラウズコマンドマニュアル全体をインラインで複製しないでください。
browseスキルを使用してください。 - 依頼が曖昧な場合、プラットフォームを推測しないでください。
- リグレッションアセットが作成されたと言うためだけに、低信号フローを保存しないでください。
disable-model-invocationを追加しないでください。ユーザーが依頼した場合、QAは利用可能に保つべきです。context: forkを追加しないでください。結果は通常、現在の実行フロー内で必要とされます。
出力契約
以下をレポートします：
- テスト対象のターゲット
- 実行されたシナリオ
- 各シナリオの成功/失敗結果
- キャプチャされたエビデンス
- 作成されたリグレッションフローファイル
- ブロッカーまたはカバーされていないギャップ
ライセンス: Apache-2.0(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- ulpi-io
- リポジトリ
- ulpi-io/browse
- ライセンス
- Apache-2.0
- 最終更新
- 2026/4/14
Source: https://github.com/ulpi-io/browse / ライセンス: Apache-2.0
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理（非同期ジェネレータを含む）、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。