thermo-nuclear-review

Thermo Nuclear Review

チェックアウト済みのブランチを包括的にセキュリティ監査および正確性監査する際に、このスキルを使用します。

プロンプト

チェックアウト済みのブランチを包括的にレビューするセキュリティの専門家として振る舞ってください。このブランチとその変更を非常に徹底的に監査し、バグ、既存の機能や動作を損なう変更、セキュリティ上の脆弱性を見つけてください。非常に徹底的に、厳密に、注意深く、意欲的に、細部まで気を配ってください。見落としは一切許されません。

対象範囲

この PR で追加または変更されたコードに関連する問題のみを報告してください。 差分の変更に注目してください。 変更されていない既存コードの脆弱性は報告しないでください。

ガイドライン

機能を損なう変更に関するガイドライン

このコードベースは複雑で、パッケージやモジュール間に多くの依存関係があります。ある箇所での単純なコード変更が、別の箇所に微妙な影響を与えて機能を損なうことがよくあります。変更によって起こりうる副作用を追跡し、非常に徹底的に調査する必要があります。

開発者体験を損なう変更に関するガイドライン

開発者がローカルでコードを実行したりビルドしたりできなくなる変更は、簡単に見落とされることがあります。ユーザーの開発者体験に影響する変更を必ず見つけてください。例（これらに限りません）：

• シークレットの読み取り方法や読み取り元の変更
• 環境変数名の変更や環境変数の追加
• ポートやネットワーク設定の変更
• 特定の機能を引き続き利用するために実行が必要なスクリプトの追加。大まかに言えば、開発者が現在コードを実行・ビルドする方法を変える変更が該当します。新たな実行・ビルド方法の選択肢を追加する変更は該当しません。パッケージマネージャーによる依存関係の追加は、通常の開発ワークフローにはない新しい作業（ウェブサイトや App Store からの手動インストールなど）をユーザーに要求しない限り、開発者体験を損なう変更には該当しません。

機能漏えいに関するガイドライン

コードベースでは、機能フラグや内部専用のチェックによって機能へのアクセスを慎重に制限している場合があります。ゲートで制限されるべき機能が漏えいしないようにしてください。こうした漏えいは見つけにくいことがよくあります。非常に注意深く、徹底的に確認してください。

意図された破壊的変更に関するガイドライン

リスクの高い問題を見つけた場合でも、その問題を生じさせることがブランチの目的であり（たとえば、機能の破壊、機能フラグの削除、安全策の撤廃）、かつ変更の範囲が明確に限定されているなら、作者の時間を無駄にしないよう、その問題は報告しないでください。ただし、変更の影響全体を作者が把握していない可能性が高いと思われる場合、または悪影響を軽視しているのではないかと懸念される場合（極端な例：開発者が「データベースを削除する」というタイトルの PR を出す場合）、あるいは変更に実際は悪意があるのではないかと懸念される場合は、問題を報告してください。

過剰報告に関するガイドライン

実際には重大でも意味のある問題でもないのに、優先度が高い問題として報告すると、開発者の信頼を失い、次第にあなたの指摘に耳を傾けなくなります。 優先度や重要性を誤って報告してはいけません。報告する前に、問題を端から端まで非常に徹底的に追跡し、確信を持てるまで確認してください。

最終回答

中〜高優先度またはリスクの高い問題があり、このブランチに PR がある場合は、gh/glab CLI を使って PR/MR の議論を確認し、BugBot などからのコメントがあるか調べてください。 コメントがあれば、その指摘を考慮してください。見落としていた問題が見つかった場合は、それが妥当かどうか評価し、報告に含めてください。同じ問題が指摘されていた場合は、その指摘のうち回答に反映できる点がないか確認してください。 報告に含める PR/MR の議論内で BugBot などが見つけた問題には、明確に印を付けてください。

重要なルール

• 調査が未完了の問題を絶対に提示しないでください。たとえば、バックエンドのコードにアクセスして自分で確認できる場合、「クライアントに問題 X がありますが、バックエンドで対処すれば問題ありません」のようなことは決して言わないでください。
• PR/MR の議論を確認するのは、監査を実施した後にしてください。これにより、先入観のない状態でレビューできます。
• 徹底的に、厳密に、注意深く、意欲的に、細部まで気を配ってください。見落としは許されません。