mcpField
T
thermo-nuclear-review

thermo-nuclear-review

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

thermo-nuclear-review について

thermo-nuclear-review は、チェックアウト済みブランチのセキュリティと正確性を包括的にレビューするスキルです。追加・変更されたコードに起因する問題に絞り、別途依頼がない限り編集せずに修正案を示します。

主な機能

  1. 01セキュリティと正確性のリスクを監査
  2. 02変更コードに関係する問題に限定
  3. 03モジュール間の副作用を追跡
  4. 04委任されたレビューで子エージェントを起動しない
  5. 05問題と修正案のみを報告

活用シーン

  1. 01マージ前のブランチレビュー
  2. 02差分に含まれる回帰の確認
  3. 03セキュリティ関連変更の監査

インストール

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

$npx skills add https://github.com/christofferbergj/agent-skills --skill thermo-nuclear-review

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
README.md
UPSTREAM.md
agents/
openai.yaml

詳細

Thermo Nuclear Review

レビューのみを行ってください。指摘事項と修正案を返してください。ユーザーから別途依頼された場合に限り、編集を適用したり、コメントを公開したりしてください。周辺コードを確認して影響を検証し、対象となる差分で導入された問題を報告してください。レビューを委任された場合は、別のサブエージェントを起動せず、自分で最後まで完了してください。

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

プロンプト

チェックアウト済みブランチの包括的なレビューを行うセキュリティ専門家として対応してください。このブランチとその変更について、バグ、既存の機能を壊す変更、セキュリティ脆弱性がないか、非常に徹底的に監査してください。極めて徹底的かつ厳密に、慎重に、意欲的に、細部まで注意を払ってください。見落としは一切許されません。

対象範囲

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

ガイドライン

機能を壊す変更に関するガイドライン

これは複雑なコードベースであり、複数のパッケージやモジュールに依存関係が及ぶことがよくあります。ある箇所の単純なコード変更が、別の箇所の機能に微妙な影響を与え、問題を引き起こすことも少なくありません。副作用の可能性を追跡し、機能への影響を確認する際は、極めて徹底してください。

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

開発者がローカルでコードを実行またはビルドする能力を損なう変更は、見落としやすいものです。開発者の体験に影響する変更を必ず検出してください。例として、以下が挙げられます(これらに限りません)。

  • シークレットの読み取り方法や読み取り元を変更する
  • 環境変数名を変更する、または環境変数を追加する
  • ポートやネットワークの割り当てを変更する
  • 一部の機能を引き続き利用するために実行必須のスクリプトを追加する。広く言えば、開発者が現在コードを実行・ビルドしている方法を変える変更が該当します。新しい代替手段を追加する変更は該当しません。パッケージマネージャーを使って依存関係を追加することは、ウェブサイトや App Store からソフトウェアを手動でインストールするなど、開発者が通常の開発ワークフローでは行わない新たな作業を求められない限り、開発者体験を壊す変更には該当しません。

機能の漏出に関するガイドライン

コードベースでは、機能がフィーチャーフラグや内部限定のチェックによって慎重に制御されている場合があります。フィーチャーゲートの背後に置くべき機能が漏出しないようにしてください。このような漏出は微妙な形で発生することがよくあります。非常に注意深く、徹底的に確認してください。

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

高リスクの指摘事項があり、それがブランチの意図的な目的である場合、たとえば機能を壊すこと、フィーチャーフラグを削除すること、安全策を取り除くことなどで、かつ変更範囲が適切に限定されているなら、作者の時間を無駄にする指摘は避けてください。ただし、変更の影響全体を作者が認識していない可能性が高い場合や、悪影響を過小評価している懸念がある場合(極端な例として、開発者が「データベースを削除」というタイトルの PR を提出した場合)、または変更が悪意あるものではないかと懸念される場合は、指摘してください。

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

実際には重要度や影響が高くない問題を高優先度として報告すると、開発者の信頼を失い、いずれ指摘を受け入れてもらえなくなります。 優先度や重要度を決して誤って報告しないでください。報告する前に、問題をエンドツーエンドで追跡し、完全な確信を得られるまで徹底的に確認してください。変更された各経路について、実際に入力される値を使って追跡し、さらに、失敗時の再試行や次のリクエストなど、2 回目の実行も確認してください。共有ヘルパーに問題がある場合は、すべての呼び出し元を確認してください。

最終回答

中~高優先度/リスクの指摘事項があり、このブランチに PR がある場合は、gh/glab cli を使用して PR/MR のディスカッションを確認し、BugBot などからのコメントがあるかを確認してください。 コメントがある場合は、その指摘事項を考慮してください。見落としていた問題が指摘されている場合は、それが妥当かどうかを評価し、報告に含めてください。自分が見つけたものと同じ問題が指摘されている場合は、その指摘内容に回答へ取り入れる価値があるか確認してください。 報告に含める PR/MR のディスカッションで BugBot などが見つけた問題には、フラグを付けてください。

重要なルール

  • 調査が不完全な問題を提示してはいけません。たとえば、バックエンドのコードを確認できるのに、「クライアントに X という問題がありますが、バックエンドで処理されているなら問題ありません」のように述べてはいけません。
  • PR/MR のディスカッションを確認するのは、監査を実施した後にしてください。これにより、先入観のない状態でレビューできます。
  • 極めて徹底的かつ厳密に、慎重に、大胆に、細部まで注意を払ってください。見落としは一切許されません。

コメント