code-review

Basic Machines のレビュー

通常のコードレビューで Basic Machines のハウススタイルとアーキテクチャの判断が必要となる、リポジトリ内のレビューにこのスキルを使用します。報告するのは指摘事項のみです。ユーザーから特定の指摘事項の修正を求められない限り、コードは編集しないでください。

対象範囲

現在の差分または指定されたファイルを、以下に照らしてレビューします。

• リポジトリの AGENTS.md / CLAUDE.md
• docs/ENGINEERING_STYLE.md
• 変更されたコードパスとテスト

アクティブなリポジトリに適用されるガイダンスのみを適用してください。basic-memory では、ローカルファーストのファイル／データベース／MCP の境界を優先してください。basic-memory-cloud では、テナント／ワークスペースの分離、クラウドワーカーの動作、web-v2 の状態／ランタイム境界を優先してください。

レビュールーブリック

具体的で反証可能なリスクのみを報告してください。

• 認知負荷： 変更は、問題の解決に必要な範囲を超えて理解しにくくなっていませんか？
• 変更の波及： 製品の変更によって、無関係なレイヤーにまたがる修正が必要になりませんか？
• 知識の重複： 同じルールが複数の箇所に記述され、ずれが生じる可能性はありませんか？
• 偶発的な複雑さ： 必要のない抽象化、フォールバック、状態が追加されていませんか？
• 依存関係の方向： API／MCP／CLI、サービス、リポジトリ、UI ストアは、意図された境界を守っていますか？
• ドメインモデルの歪み： 名前と型は製品の概念に合っていますか？それとも、転送やストレージの詳細がドメインに漏れていますか？
• テストオラクルの品質： テストは、変更で防ぐとされているバグやリグレッションがあれば失敗しますか？

明示的に確認するハウスルール

• 不明なモデル形状に対して、推測で getattr(obj, "attr", default) を使用しないでください。
• 広範な例外の握りつぶし、警告だけで終わる失敗パス、隠れたフォールバック動作を使用しないでください。
• 不明瞭な型の関係を隠すキャストや Any を使用しないでください。
• 内部の値／結果オブジェクトにはデータクラスを使用し、検証／シリアライゼーションの境界では Pydantic を使用してください。
• 必要な機能だけを備えた、範囲の狭い Protocol を使用してください。
• 非同期処理／リソースの所有権、キャンセル、クリーンアップを明示してください。
• リスクの高い変更には、意味のあるリグレッションテストまたは検証を用意してください。
• コメントでは何をするかではなく、なぜそうするかを説明してください。

報告形式

重要度の高い順に指摘事項を先頭に記載してください。各指摘事項には、以下を含めてください。

重要度	用途
high	正確性、セキュリティ、データ損失、またはテナント／ワークスペース分離に関する、発生可能性の高い不具合
medium	将来の不具合につながり得る、具体的な保守性または境界上のリスク
low	軽微な一貫性の問題、曖昧なガイダンス、またはレビュー上の整理事項

severity | file:line | risk category | claim
Why: concrete behavior or code path that proves the risk.
Fix: smallest practical change, or "none obvious" if the risk needs product input.

指摘事項がない場合は、その旨を伝え、残っている検証上の不足があれば記載してください。