mcpField
S
specsfy-specialist-code-review

specsfy-specialist-code-review

github.com/promovawebテスト・品質87181 回インストール1 週間前に更新
リポジトリ

specsfy-specialist-code-review について

specsfy-specialist-code-reviewは、マージやリリース前に既存のdiff、ブランチ、PRを評価するコードレビュースキルです。仕様やコードの呼び出し関係に照らして指摘を確認し、重大度、場所、発生条件、影響、修正案をまとめます。

主な機能

  1. 01比較基準とレビュー範囲の明確化
  2. 02仕様・受け入れ条件との照合
  3. 03正確性・セキュリティ・並行処理の確認
  4. 04テストが動作を証明するかの検証
  5. 05重大度別の具体的な指摘

活用シーン

  1. 01マージやリリース前のPRレビュー
  2. 02作成済み変更へのセカンドオピニオン
  3. 03セキュリティ関連変更の具体的なリスク確認
  4. 04テストが変更後の動作をカバーするかの確認

インストール

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

$npx skills add https://github.com/promovaweb/specsfy --skill specsfy-specialist-code-review

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

同梱ファイルagents/openai.yamlreferences/standards.md

詳細

コードレビュー

使用する場面

  • マージまたは公開する前に評価する具体的な diff、ブランチ、PR がある場合に実行します。
  • PR がまだ作成されていなくても、すでに書かれた変更について「セカンドオピニオン」を求められた場合にも実行します。
  • 新しい構造上の判断をゼロから設計する場合には実行しません。その場合は $specsfy-specialist-software-architecture を使用してください。レビューでは、すでに決定され、書かれた内容を評価します。判断そのものに取って代わるものではありません。
  • diff が認証、認可、機密データ、外部入力に触れる場合は $specsfy-specialist-application-security と、問題点が紛らわしい名前、不変条件、ドメイン境界に関する場合は $specsfy-specialist-domain-modeling と組み合わせてください。

手順

  1. 比較のベースと diff の正確な範囲を確定します。明確なベースなしに diff をレビューすると、変更が触れていないコードに関する指摘が生じます。
  2. 判断する前に、適用される仕様、issue、受け入れ条件、リポジトリの指示を確認します。そうしなければ、「正しいかどうか」は個人的な意見になってしまいます。
  3. 変更された各ファイルを、それが影響する動作と境界(データ、権限、API 契約、設定、依存関係)に対応付けます。
  4. スタイルより先に、正確性、境界事例、セキュリティ、並行処理、運用上の影響を評価します。スタイルがブロッカーとなるのは、自動化で対応されていない場合だけです。
  5. テストがどのような証拠を示すかを確認します。修正がなければ失敗するでしょうか。それとも行をカバーしているだけで、動作を証明していないでしょうか。
  6. 疑わしい指摘を報告する前に、実際のコードと呼び出し元/利用側を読んで確認し、誤検知を減らします。
  7. 重要度順に、正確な位置(ファイル:行)、失敗が起きる条件、影響、想定される修正を添えて報告します。

基準

  • バグと具体的なリスクを優先し、スタイルの好みをブロッカーにしないでください。
  • 各指摘には、入力条件、観測可能な結果、それを裏付ける証拠(行、テスト、ログ)を記載します。
  • ハッピーパスだけでなく、既存クライアントとの互換性、並行処理、ロールバック計画、変更の可観測性も考慮します。
  • 追加されたテストが、実際の修正なしでは失敗するか確認します。変更の前後で通るテストは、何も証明しません。
  • PR の対象範囲から漏れていること(マージをブロックする問題)と、将来任意で行う改善(コメントのみでブロックしない)を区別します。
  • リンター、フォーマッター、型チェッカーがすでに自動で検出する指摘を繰り返さないでください。自動化で検出できない点だけを指摘します。
  • 該当する場合は「この観点では指摘なし」と明記し、観察した範囲を超えてリスクがないと受け取られる表現は避けます。

アンチパターン

  • プロジェクトですでにリンターが設定されているのに、変数名や書式の好みを理由にブロックすること。重要な指摘に使うべきレビューの注意力を浪費します。
  • 新しいテストが変更の動作を実際にカバーしているか(循環的なテストや実質的なアサーションのないテスト)確認せず、「テストが通る」ことを理由に承認すること。
  • ファイルごとにレビューし、ファイル間の流れを把握しないこと。たとえば、関数のシグネチャが変わったのにすべての呼び出し元が更新されていない、といった相互作用を見落とします。
  • 具体的な攻撃経路を示さずに「安全でないように見える」と報告すること。信頼境界と具体的な入力を示さないセキュリティ上の指摘は、対応につながりません。

検証

  • 設定ファイル、マイグレーション、動作に影響される diff 外の呼び出し元/利用側も含め、diff 全体をレビューします。
  • 報告する各指摘について、公開前に実際のコードとテストスイートの状態を照合します。確認できていない指摘はレポートに含めません。
  • 最終リストは、ファイルが diff に現れる順ではなく、重要度(発生確率 × 影響度)順に並べます。
  • 最後に、レビューで確認した範囲と、確認できなかった残存リスクをまとめます。
  • 上記の証拠なしに diff を「安全」または「正しい」と断言してはいけません。根拠のない断定的な表現は禁止です。

関連スキル

  • $specsfy-specialist-debugging は、レビューでまだ説明されていない不具合が見つかった場合に、再現方法と根本原因を提示します。
  • $specsfy-specialist-typescript は型コントラクトを詳しく確認し、$specsfy-specialist-web-accessibility は差分に関連するリスクがある場合に、セマンティクス、キーボード操作、WCAG を詳しく確認します。
  • 差分がアイデンティティ、認可、機密データ、外部入力に関わる場合は、$specsfy-specialist-application-security を利用してください。セキュリティレビューでは、このスキルが指摘するだけの内容をさらに掘り下げます。
  • 指摘内容が、差分そのものだけでなく、差分によって明らかになった結合、境界、構造上の決定に関する場合は、$specsfy-specialist-software-architecture を利用してください。
  • 競合を解決した後にレビューをやり直す必要がある場合は、$specsfy-specialist-merge-conflict-resolution を利用してください。競合解決によって、最終的な動作が変わる可能性があります。

レビューの観点、重大度の尺度、指摘の形式、公式な参照元については、references/standards.md をお読みください。

コメント