review-an-app

アプリをレビューする

すでに存在するアプリを見て、何が問題なのかを指摘します。別の、より大規模で成熟したアプリならどうあるべきかではなく、このアプリ自身について何が間違っているのかを見ます。

これはコードレビューでも、デプロイの可否を判断するものでもありません。 /code-review は保留中の差分を読み取り、このブランチより前から存在する問題には気づきません。deploy-an-app はデプロイしてよいかを判断します。start-an-app の批評では、アプリのひな型を作成した日に書かれたビルド仕様に照らして評価します。この3つはいずれもアプリ以外のものを基準にしているため、運用開始から6か月たったアプリは、そのどれもすり抜けてしまいます。このスキルでは、今あるアプリそのものをレビューします。

基本ルール

• アプリ自身が仕様です。 ここにビルド仕様はなく、照らし合わせる基準はアプリ自身の主張だけです。ランディングページで何を売りにしているか、ドキュメントで何を指示しているか、プライバシーポリシーで何を約束しているか、サイトマップでクローラーに何を開くよう促しているか、ボタンが表示されたときに何を示唆するか。指摘事項とは、アプリが述べていることと実際の動作との矛盾です。それ以外は提案であり、提案は指摘事項ではありません。
• ないこと自体は指摘事項ではありません。 「レート制限がない」「テストがない」「構造化データの追加を検討する」――これらはいずれも、アプリが間違えたことではありません。より大きなアプリになら備わっているものです。このスキルを最も手っ取り早く無価値にするのは、成熟した製品なら備えているものを列挙することです。そのレポートは一度ざっと読まれたきり、二度と見返されません。
• 読み取り専用です。 このスキルはアプリを編集しません。読み取りコマンドを実行し、調査のためにアプリを起動することはありますが、何も変更しません。修正は別途明示的に依頼された場合に行います。ステップ6で、ユーザーから依頼があったときに限ります。
• パターンではなく、影響を示します。 各指摘事項では、誰がどのような影響を受けるかを説明します。「このクエリはユーザーごとに絞り込まれていない」はパターンです。「ログイン済みのアカウントであれば、URLのIDを変更するだけで、ほかのすべてのアカウントの請求書を読めてしまいます。src/app/invoices/[id]/page.tsx:14」が指摘事項です。外部から問題に至る経路を説明できないなら、まだ指摘事項ではありません。
• 実行していないチェックは、実行していないと明記し、実行したとは決して主張しません。 この一連のスキル全体に共通するルールです。アプリを起動できなかった場合、キーがなかった場合、ブラウザーが必要なルートがあった場合は、そのために実施できなかったチェックと、実施するために必要なことを伝えます。何も触れなければ、チェックを通過したように受け取られます。
• アプリが安全だと結論づけてはいけません。 どんなレビューも、安全性を証明するものではありません。締めくくりの文では、チェックした内容とチェックしなかった内容を正直に明記します。「脆弱性は見つかりませんでした」は、このスキルが決して書いてはならない文です。後になって確認をやめた人に引用されることになるからです。
• ユーザーの選択は指摘事項ではありません。 自分なら別の技術スタックを選ぶ、デザインが好みではない、意図的にアプリを検索対象から外している――これらはいずれも間違いではありません。選択が偶然の産物に見える場合は、その選択ではなく、偶然だったことを示す証拠を報告します。
• バージョン番号を書いたり、記載を受け入れたりしてはいけません。 コマンドにも、文章にも、パッケージの固定にも記載しません。AI クローラーのユーザーエージェントトークン、アドバイザリーデータベース、フレームワークのファイル規約など、変わりうるものにチェックが依存する場合は、レビュー時点で確認します。
• 観点には証拠を渡し、アクセス権は渡しません。 観点ごとにポートやブラウザーを共有することはできません。また、実行権限のある観点は、割り当てられた時間を実行に費やします。ステップ2で一度だけ情報を取得して共有し、それを読んでもらいます。

Step 1 — 概要を把握する

何を確認するか決める前に、このアプリが何なのかを把握します。ここで10分かければ、ほとんどのノイズを取り除けます。アプリに決済機能がないと把握していれば、Webhook の検証を探し回ることはありません。

質問するのではなく、コードから次の点を確認します。

• スタック。 package.json、フレームワーク、ルーター、ORM、認証ライブラリを確認します。このスキルは、start-an-app が構築するもの、つまり Next.js App Router、Better Auth、Drizzle、Postgres または SQLite を対象にしています。それ以外のものに遭遇した場合は、レポートでその点を明確にし、どのチェックの有効性が弱まるかを説明してください。 対応していないスタックを完全にカバーしているかのように装うレビューよりも、対応範囲の限界を明示するレビューのほうが優れています。
• 存在する機能。 サインイン、メール、アップロード、決済、AI、バックグラウンドジョブ、MCP 経由のエージェントアクセス、ドキュメント、法的ページ、同意バナーなどです。それぞれの機能によって、レンズの該当セクションが有効になり、さらに重要なことに、その他のセクションは無効になります。
• アプリが見つけられることを意図しているか。 robots.ts、robots.txt、ルートレイアウトのメタデータを確認します。これによって見つけやすさのレンズ全体の形が決まり、判断を誤ると、内部ツールの最適化を勧めるレポートになってしまいます。
• アプリが何をうたっているか。 ランディングページ、ドキュメント、法的ページ、料金を確認します。これらが仕様なので、それに照らしてレビューする前に読んでください。

これからレビューする内容と、実行するレンズを2行で伝えます。ユーザーが1つのレンズだけを指定した場合は、そのレンズだけを実行してください。

Step 2 — 証拠を一度だけ収集する

references/evidence.md に、ルート一覧、アプリの起動確認、プローブの一括実行、記録する内容などのコマンドがあります。3つのレンズが同じ記録を使うため、収集は一度だけ行い、いずれかを開始する前に完全な状態にしておく必要があります。

絶対ルール：証拠パックにシークレットを含めてはいけません。 サブエージェントに渡され、レポートで引用されます。.env から取得するのは変数の名前だけで、値は含めません。git diff と配信された HTML は漏えいがないか確認しますが、全体を貼り付けてはいけません。確認対象のキーそのものを漏えいさせることだけが、このスキルによって実害が生じる唯一の方法です。

ステップ 3 — レンズを実行する

1つのメッセージでディスパッチし、同時に実行します。 それぞれ読み取り専用で、エビデンスパックを受け取り、独自のブリーフに従います。ブリーフはリファレンスファイルにあります。

レンズ	リファレンス	対象
セキュリティ	references/security.md	OWASP Top 10。このスタックで実際に問題となっている点に基づきます
発見可能性	references/seo.md	サイトマップ、robots.txt、llms.txt、メタデータが正しく最新かどうか
ドリフト	references/drift.md	アプリが何を主張し、実際に何をするか

各レンズには、ブリーフとして独自のリファレンスファイルだけを渡し、それ以外は何も渡しません。このファイルも、他のレンズの出力も渡しません。他のレンズの調査結果を見られるレンズは、それに同調し始めます。意見が一致するエージェントが3つ並ぶと、実際には単なる反響にすぎないものが、裏付けのように見えてしまいます。

ここにあるリファレンスファイルはレビュー担当者に渡すために書かれており、アプリの構築に使ったファイルを批評者に見せないという start-an-app のルールとは正反対です。違いはファイルの用途にあります。前者は構築手順なので、批評者に渡すとチェックリストをなぞるだけの役割に戻ってしまいます。こちらはレビュアー向けに書かれています。

どのレンズからの指摘も、同じ形式で返されます。

内容 — 問題点を1文で示します。 場所 — path:line、またはルートとその応答内容です。 矛盾 — アプリが何を主張し、どこで主張しているかです。セキュリティの場合は、外部から欠陥に至るまでの経路です。 確度 — ファイル、コマンド、または応答で証明できる場合は saw it、そのように見えるものの確認できなかった場合は suspect です。 重大度 — broken（現時点で誤っており、影響を受ける人がいる）、at risk（現在は動作するものの、偶然に頼っている — 本来防ぐべきガードがない）、または worth knowing（事実ではあるが影響は小さく、対応不要）です。

軽微な指摘には上限を設け、重大な指摘は決して省きません。 1つのレンズから worth knowing が8件を大きく超えて出てくる場合は、実際の指摘が尽き、数を埋め始めています。確認済みの broken 指摘は、件数制限に合わせて省略してはいけません。

ステップ 4 — 照合する

レンズによる確認は終わりましたが、まだどれも正しいとは限りません。

• すべての suspect を、レポートに含める前にコマンドで再確認します。 これがレビューと推測を分けるステップであり、必要なものの大半はすでにエビデンスパックに含まれています。コマンドの結果が指摘と一致しない場合は、その指摘を削除し、確認した結果問題がなかったことを1行で記します。
• レンズ間で重複を取り除きます。 何も削除を実行していないのにプライバシーポリシーが削除を約束しているなら、ドリフトの指摘とセキュリティの指摘ではなく、1つの指摘です。最も適切に影響を示している方を残します。
• 矛盾または場所を特定できない指摘は削除します。 この時点で、指摘には path:line、応答、またはアプリ自身のページからの引用のいずれかがあるはずです。どれもない場合は、テンプレートをまとっただけの意見です。
• 2つのレンズの見解が食い違う場合： path:line を示している方を採用します。両方とも示している場合は、本当の曖昧さがあるため、1つにまとめてレポートに記載します。
• レンズではなく、影響の大きさで順位付けします。 レポートは1つの順序付きリストです。検証されていない決済 Webhook と古い llms.txt を、別々のエージェントから出たというだけで同じセクションに含めてはいけません。

Step 5 — レポート

リスクの高いものから順に、コードを読まない人にも分かる平易な言葉で報告します。

まず件数と全体像を伝えます。「問題が4件あり、そのうち1件は深刻です」のように述べてから、各指摘を示します。各指摘では、問題の内容と場所、利用者にとって重要な理由、修正に必要な作業を説明します。中身のない重大度一覧表は作成しません。該当する観点で問題が見つからなかった場合は、その旨を1行で記載します。これは失敗ではなく、確認結果です。

続いて、レポートの誠実さを支える次の点を説明します。

• 何を、どのように確認したか。 アプリを実行して確認したのか、コードを読んだだけなのかを明記します。この違いによって確信度は大きく変わりますが、指摘内容だけでは読み手に判断できません。
• 何を確認していないか、確認には何が必要か。 ブラウザー、キー、実際の決済、本番環境のドメインなど、それぞれ明記します。
• 締めくくりの文で、アプリが安全だとは決して断言しません。 このレビューで確認した範囲を述べます。

項目が多い場合やユーザーがレポートを共有する場合は、ターミナルのスクロールバックに残すのではなく、ページとして公開することを提案します。

Step 6 — 求められた場合に限り修正

レビューは Step 5 で終了します。その後ユーザーから修正を求められた場合は、次のとおり対応します。

• broken と確認された指摘を最初に、一度に1件ずつ修正し、その都度検証します。
• 修正対象は、指摘で指定されたファイルだけです。 リファクタリング、整理、「ついでの修正」は行いません。これは誰かが実際に使っているアプリであり、ひな形ではありません。
• スキーマ変更が必要な修正では、db:generate を実行し、生成された SQL を読んでから db:migrate を実行します。 push は決して実行せず、適用済みのマイグレーションも編集しません。
• worth knowing の一覧にある項目は、ユーザーが名前を挙げて指定しない限り修正しません。
• 修正のたびに関連するチェックを再実行し、別の問題が発生した場合は明確に伝えます。