mcpField
A
audit-my-app

audit-my-app

github.com/reticlehqテスト・品質1.3k254 回インストール今日更新
リポジトリ

audit-my-app について

audit-my-appは、実行中のアプリを監査するReticleスキルです。コントロールの探索、API結果と画面表示の比較、テストカバレッジの確認を行います。確定した不具合と未検証の箇所を区別し、ソース位置付きで報告します。

主な機能

  1. 01アプリが示すテスト対象を確認
  2. 02到達可能なコントロールを巡回して異常を検出
  3. 03API応答と画面表示を比較
  4. 04検証済み範囲と未確認範囲を報告
  5. 05保存済みフローのアサーションを確認
  6. 06不具合、未検証箇所、既存の問題を分類

活用シーン

  1. 01開発環境で反応しないコントロールを監査
  2. 02APIデータと画面表示の不一致を発見
  3. 03未確認のコントロールやフローを特定
  4. 04ファイル名と行番号を添えて調査結果を要約

MCP 対応

このスキルはreticle_capabilities、reticle_verify、reticle_explore、reticle_reconcile、reticle_domainなどのReticle MCPツールでアプリを調査・監査します。

インストール

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

$npx skills add https://github.com/reticlehq/reticle --skill audit-my-app

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

詳細

アプリ全体を調査して、不具合を報告する

確認するために、コードベースを理解する必要はありません。Reticle は実行中のアプリで、到達可能なすべてのコントロールを操作し、異常を報告します。まだセットアップしていませんか？reticle スキルに従ってください。Reticle をインストールし、init によるアプリのファイルの変更前にユーザーに確認し、1 つのフローを検証します。

1. アプリにできることを尋ねる

reticle_run({ tool: "reticle_capabilities", args: { sessionId } })

約 1 KB で、アプリがテスト可能な範囲を自ら説明します。登録されたすべての testid、すべてのドメインシグナル、ストア、保存済みフローとその手順です。DOM のスナップショットを取得して要素名から意図を推測するよりも確実で、最も手軽に全体像を把握できます。

2. すべてをクリックする

reticle_run({ tool: "reticle_verify", sessionId, args: { action: "crawl", maxSteps: 25 } })

{
  "interactiveFound": 3,
  "stepsRun": 3,
  "anomalies": [],
  "counts": { "consoleErrors": 0, "failedRequests": 0, "deadControls": 0, "contradictions": 0 },
  "visited": ["- textbox \"Email\"", "- button \"Sign in\""],
  "truncated": false
}

実際の問題を示すカウントは、deadControls と contradictions の 2 つです。 コンソールエラーやリクエストの失敗も確認する価値はありますが、アプリが活発に動作していれば、どちらも問題なく発生します。応答のないコントロールは何にも接続されていないボタン、矛盾は画面に表示された内容と異なるチャネルです。

すべてをクリックするため、開発環境を指定してください。maxSteps で上限を設定でき、デフォルトは 25 です。最初に、操作せずに到達可能な範囲だけを確認したい場合は、reticle_run({ tool: "reticle_explore", sessionId }) を実行してください。

この調査を独自に実装しないでください。よくある方法（各コントロールをクリックして、コンソールエラーがないことを確認する）は、まさに調査対象のバグがあるときに限ってテストを通過します。応答のないボタンは何もエラーを出さないからです。

3. API の応答と描画結果を比較する

reticle_run({ tool: "reticle_reconcile", sessionId })

API は 10 行を返し、テーブルには 9 行が表示され、エラーは発生しませんでした。ネットワークログにも DOM にも、それぞれ単独では問題がありません。この比較を行って初めて不一致が見つかります。この比較を実行できるものは、ほかにはありません。

4. まだ誰も操作していない箇所を見つける

reticle_run({ tool: "reticle_verify", sessionId, args: { action: "coverage" } })   // { total, exercised, untouched }

プロジェクトにすでに保存済みのフローがある場合は、それらが何かを検証できているかも確認してください。

reticle_run({ tool: "reticle_domain", sessionId })
// → { flowCount, coverage: { asserted, presenceOnly, assertionFree }, gaps: { declaredUntestedSignals, … } }

40 件のフローがあるスイートのうち 31 件が何も検証していなければ、どんなリグレッションが起きてもテストを通過し続けます。この数値は通常、監査全体で最も懸念すべきものであり、これを報告できるものはほかにありません。

5. 報告する

まずカウントを示し、実際に見つかった問題を 1 件ずつ、reticle_look { action: "element" } で確認した file:line とともに 1 行で記載します。次のように分類してください。

  • 不具合：応答のないコントロール、矛盾、失敗したリクエスト、調査中に発生したエラー。
  • 未検証：untouched コントロールと assertionFree フロー。壊れていると判明したわけではなく、未確認であることがわかっている項目です。
  • 既存の問題：調査開始前から発生していたコンソールエラーです。今日の変更が原因だと誤解されないよう、その旨を明記してください。

一部しか調査していないのに、問題のない監査結果として報告しないでください。 truncated が true の場合、または maxSteps によって調査が途中で止まった場合は、到達できなかった範囲を明記してください。上限に達したことを黙っていると、「すべて問題なし」と受け取られてしまいますが、実際には「途中で止めた」という意味です。

機能の全リファレンス：curl https://docs.reticle.sh/capabilities.md。そのほかの情報：curl https://docs.reticle.sh/llms.txt。

コメント

Markdown 対応