mcpField
R
review

review

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

review について

reviewは、Keboolaコンポーネントのコードを審査するスキルです。コード品質と後方互換性を一度に確認し、最初にruffを実行するとともに、公開リポジトリでの識別情報の保護を徹底します。

主な機能

  1. 01品質と互換性の一括レビュー
  2. 02最初にruffを実行
  3. 03設定と出力の変更を分析
  4. 04リスク別の指摘整理
  5. 05テレメトリーデータの匿名化

活用シーン

  1. 01コンポーネントのPull Request審査
  2. 02設定変更の互換性確認
  3. 03テレメトリーなしでの変更リスク評価

インストール

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

$npx skills add https://github.com/keboola/ai-kit --skill review

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

同梱ファイル

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

references/
breaking-changes.md
code-quality.md
telemetry.md

詳細

Keboola Component Reviewer

ユーザーからどちらか一方だけを求められない限り、コード品質レビューと後方互換性レビューの両方を一度に実施してください。

重要：リポジトリは公開されています。PR コメントを含め、クライアント名、プロジェクト名、スタック URL、その他の個人を特定できる情報は、どこにも記載しないでください。匿名化した集計値のみ使用してください。

1. 対象範囲

デフォルト：PR の場合は git diff $(git merge-base HEAD main)..HEAD、ステージングされていない変更の場合は git diff。 指定あり：ユーザーが指定したファイルまたはディレクトリ。

2. 自動チェック（最初に実行）

手動レビューを始める前に ruff を実行してください。書式とリントの問題を機械的に検出できます。

uv run ruff format --check . 2>&1
uv run ruff check --target-version py313 . 2>&1

どちらか一方でも失敗した場合は、単一の項目として「run ruff format . && ruff check --fix .」と報告してください。個別の書式やリントの問題を列挙しないでください。それは ruff の役割です。ruff が検出するレビュー項目は省略してください。

3. コード品質レビュー

ruff では検出できない点に注目してください。優先順位は次のとおりです。

ブロッキング — アーキテクチャ上の違反：

  • run() が明確なオーケストレーターになっていない（目次のように読め、30 行未満であるべきです）
  • __init__ ではなく run() 内でクライアントや設定を初期化している（sync_actions が機能しなくなります）
  • 設定が型付きオブジェクト（Pydantic BaseModel または dataclass）にカプセル化されていない

重要 — 品質向上：

  • パブリックメソッドに型ヒントがない
  • 非推奨の typing インポート（typing.List、typing.Dict、typing.Optional）を使用している — 組み込み型を使用してください
  • コード内の各所で、設定値に self.configuration.parameters.get(...) を直接使ってアクセスしている

確信度が 60 以上の問題のみ報告してください。詳細なパターンと例については、code-quality.md を参照してください。

4. 後方互換性レビュー

ステップ 1：コンポーネント ID を特定する
grep -E 'KBC_DEVELOPERPORTAL_APP|APP_ID' .github/workflows/push*.yml

単一の環境変数、複数の接尾辞付き環境変数、マトリックス戦略のパターンに対応します。

ステップ 2：差分を分析する
git diff $(git merge-base HEAD main)..HEAD -- \
  'component_config/' 'src/configuration.py' 'src/component.py' 'Dockerfile' '.github/workflows/'

breaking-changes.md の破壊的変更の観点に照らして、変更された各ファイルを確認してください。対象は、設定スキーマ、Pydantic モデル、同期アクション、出力テーブル、状態ファイル、Dockerfile です。

ステップ 3：テレメトリー

Keboola MCP を利用できる場合は、各コンポーネント ID のテレメトリーを照会し、アクティブな設定、ジョブの統計情報、変更または削除されたフィールドのプロパティ使用状況を確認してください。正確なクエリと匿名化のルールについては、telemetry.md を参照してください。

MCP を利用できない場合は、その旨を明示し、すべての変更を慎重に扱ってください（設定が存在するものと仮定します）。

5. 出力

まず全体評価を 1～2 文で述べ、続けて次の内容を記載してください。

コード品質 — TODO をブロッキング／重要／あれば望ましい、の各グループに分けてください。

### TODO N: [Title]
**Location:** `src/component.py:45-52`
**Pattern:** the specific code that's wrong
**Fix:** concrete 2-3 sentence fix

後方互換性 — 指摘事項を HIGH／MEDIUM／LOW／SAFE のリスク別にまとめてください。利用可能な場合はテレメトリー表を含めてください。最後に判定として APPROVE／REQUEST CHANGES／WARN のいずれかを記載してください。

建設的な口調を心がけ、率直でありながら親切に、作成者が自分で判断できるようにしてください。「you must...」より「I'd personally...」を使ってください。指摘事項がなければ「LGTM」としてください。

コメント

Markdown 対応