mcpField
F
first-five

first-five

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

first-five について

first-fiveは、指定したベースブランチからの変更を5つのリスク観点でトリアージするコードレビュー用スキルです。疑わしい点を確認し、全面的なレビューではなく、確認済みの重要事項だけを簡潔に報告します。

主な機能

  1. 01ベースブランチとの差分確認
  2. 02エラー処理と入力境界の確認
  3. 03外部呼び出しと状態変更の調査
  4. 04参照先の依存関係の検証
  5. 05確認済みの問題だけを報告

活用シーン

  1. 01レビュー前の機能ブランチのトリアージ
  2. 02変更箇所のサイレント失敗リスクの確認
  3. 03差分内の依存関係参照の検証

インストール

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

$npx skills add https://github.com/unlearndev/skills --skill first-five

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

詳細

First Five

引数

未加工の引数:$ARGUMENTS

引数を比較対象のベースブランチとして解析します。空の場合は、デフォルトで main を使用します。

目的

ベースブランチと HEAD の間で変更されたファイルを First Five チェックリストに照らして確認し、調査する価値のある項目だけを報告します。短く見やすいトリアージリストであり、完全なレビューでも、すべての行を列挙するものでもありません。

5 つのチェック項目:

  1. エラー処理 — 空の catch、失敗する可能性のある呼び出しに対するエラー処理の欠如、例外の握りつぶし、無言の失敗。
  2. 入力境界 — ユーザー入力に対する長さ/型/形式の検証不足、リクエストフィールドの未検証での使用、データベースや外部システムに渡される上限のない入力。
  3. 外部呼び出し — 存在しない可能性がある、または想定と異なる動作をする可能性のあるメソッド/ファサード/API の呼び出し(誤ったシグネチャ、誤った名前空間、トレイト/マクロの欠落)。
  4. 状態変更 — 他のコードが依存している破壊的、または予期しない書き込み(削除、上書き、カスケード)。
  5. 依存関係の想定 — コードが参照しているものの、存在しない可能性があるインポート、クラス、ファイル、ルート、ビュー、設定キー。

指示

1. 差分を取得する

git diff <base>...HEAD(3 点リーダー。分岐してからこのブランチで行われた変更)と、ファイル単位の概要を得るために git diff --name-status <base>...HEAD を実行します。変更がない場合は、その旨を伝えて終了します。

2. 変更されたファイルを確認する

変更された各ファイルについて、5 つのチェック項目に照らして評価するのに十分な範囲を読みます。予期しない点が見当たらない限り、自動生成ファイルは確認を省略します。

  • ロックファイル(composer.lock、package-lock.json、pnpm-lock.yaml など)
  • コンパイル済みアセット(public/build/、dist/)
  • 生成されたルート/型定義(Wayfinder の action/route ファイル、生成された TS 型など)
3. 報告前に検証する

疑いだけを根拠に報告してはいけません。指摘事項を列挙する前に:

  • 依存関係の想定 — find または ls を使って、インポートされたファイル/クラスが実際に存在するかどうかを確認します。本当に存在しない場合に限り報告します。
  • 外部呼び出し — レシーバークラス/ファサード上のメソッドを grep で検索します。本当に定義されていない(またはシグネチャが異なる)場合に限り報告します。
  • 入力境界 — 対応する FormRequest/バリデーター/マイグレーションのカラム型を確認します。検証が実際に欠けている、またはフィールドの使用方法に合っていない場合に限り報告します。
  • エラー処理 — 呼び出しに実際に失敗する可能性があり、かつ処理が行われていない場合に限り報告します。ジョブの自動再試行でラップされているコードや、適切に処理するグローバル例外ハンドラーがある場合は、指摘事項ではありません。
  • 状態変更 — コードベースの別の部分が、変更される状態に実際に依存している場合に限り報告します。

誤りだと確認できない場合は、報告しないでください。

4. レポートを出力する

各チェック項目につき 1 つのセクションを作成します。報告事項があるセクションだけを含めてください。問題のないセクションは省略します。「(指摘事項なし)」のようなプレースホルダーは書かないでください。

この形式を正確に使用してください。

**Error Handling**
- ⚠️ `file.php:42` — empty catch block hides notification failures
- `file.php:80` — no error handling around the API call

**Input Boundaries**
- ⚠️ `Request.php:15` — `message` field has no max length, goes into a text column

**External Calls**
- ⚠️ `Controller.php:40` — `Notification::sendLater()` doesn't exist on the facade

**State Mutations**
- `Observer.php:35` — deletes subscription permanently, other features read this relationship

**Assumed Dependencies**
- ⚠️ `Controller.php:3` — imports `App\Notifications\IdeaStatusChanged` but file doesn't exist

**X items across Y files.**

すべて問題がない場合は、次を正確に出力してください。

✅ Nothing flagged.

ルール

  • 少ないほどよい。 実際に誤りやリスクがあるものだけを指摘してください。細かな指摘を20件挙げるより、実際の問題を5件挙げるほうが有益です。
  • ⚠️は重大度が高い場合に限ります — データ損失、セキュリティ上の欠陥、サイレントな失敗、ファイルやクラスの欠落、外部呼び出しの破損が対象です。それ以外は通常の箇条書きにしてください。
  • 必ずfile:lineを含めてください。 各箇条書きは、バッククォートで囲んだパスと行番号から始めてください。
  • 指摘1件につき1行にしてください。 何が問題なのか、なぜ重要なのかを同じ行に記載してください。複数文で説明しないでください。
  • 指摘する前に依存関係を確認してください。 findまたはlsを使用してください。ファイルが存在しないという誤った指摘は、このスキルで最悪の結果です。
  • 自動生成ファイル(ロックファイル、コンパイル済みアセット、生成されたルートや型の定義)は対象外にしてください。
  • 前置きや締めくくりの要約は不要です。 **X items across Y files.**の行以外は追加しないでください。「以下が調査結果です」などの文や、修正方法に関する助言は含めないでください。
  • 修正案を提示しないでください。 これはトリアージ一覧です。懸念点を示したら、それ以上は述べないでください。
  • コードを言い換えて説明しないでください。 「if ($x) { … } — xが真かどうかを確認しています」は冗長です。コードの説明ではなく、問題点を述べてください。

コメント