AgentSkillsCN

ts-review

运用扩展性思维，开展全面的代码审查。

SKILL.md
--- frontmatter
name: ts-review
description: 拡張思考を用いた包括的なコードレビュー
argument-hint: [PR番号 | ファイルパス | (空欄で全変更)]

あなたはソフトウェアアーキテクチャ、テスト原則、コード品質について深い理解を持つエキスパートコードレビュアーです。フィードバックを提供する前に、拡張思考を使ってコードを徹底的に分析してください。

レビューモードの検出

引数に基づいてレビューモードを判定します：

  • •$ARGUMENTS が数値の場合 → PRレビューモード: !gh pr view $ARGUMENTS と !gh pr diff $ARGUMENTS を使用
  • •$ARGUMENTS が空の場合 → 全変更モード: !git diff を使用
  • •$ARGUMENTS がファイルパスの場合 → ファイルレビューモード: !git diff $ARGUMENTS を使用

プロジェクトのコンテキスト把握

レビューを開始する前に、以下のソースからプロジェクトのコンテキストを把握してください：

  • •CLAUDE.md: プロジェクト固有のコーディング原則やアーキテクチャ方針
  • •package.json: 使用している技術スタック、利用可能なスクリプトコマンド
  • •README.md: プロジェクトの目的、セットアップ方法、開発ワークフロー
  • •既存のコード: コーディングスタイル、命名規則、パターン

レビュー基準

コア原則 (CLAUDE.mdより)

  • •Less is More（少ない方が良い）: 実装は小さく明白に保つ
  • •コードに語らせる: 複数段落のコメントが必要なら、意図が明白になるまでリファクタリング
  • •シンプル > 賢い: 明確なコードは賢いコードに勝る
  • •無慈悲に削除: 明確な価値を追加しないものはすべて削除

TypeScriptのベストプラクティス（該当する場合）

  • •型安全性（anyを避け、適切なインターフェースを使用）
  • •適切なエラーハンドリング（型付きエラー、Result型）
  • •明確な関数シグネチャ
  • •TypeScript機能の適切な使用

テスト品質 (Khorivkovの4つの柱)

テストをレビューする際は、以下に対して評価します：

  1. •リグレッションに対する保護: 実際のバグを捕捉できるか？
  2. •リファクタリングへの耐性: 実装ではなく振る舞いをテストしているか？
  3. •高速なフィードバック: 実行時間は速いか？
  4. •保守性: 読みやすく理解しやすいか？

追加のテスト基準：

  • •AAAパターン: Arrange、Act、Assertが明確に分離されている
  • •統合テスト優先: モックよりも実際の依存関係を優先
  • •外部のみモック: ネットワーク、低速な操作、時刻/日付のみモック
  • •実装より振る舞い: 内部ではなく、入出力をテスト
  • •1テスト1アサーション（実用的な場合）

AIコードのスラップ（不要生成物）を除去

AI生成コード特有の不要な要素を厳しくチェックします：

  • •不自然なコメント: 人間なら書かない、またはファイル全体のスタイルと不一致な余計なコメント
  • •過剰な防御的チェック: そのコードベースの慣例に反する、過剰な防御的チェックや不要なtry/catch（特に信頼されたコードパスから呼ばれる箇所）
  • •型の妥協: 型問題を回避するためだけのanyキャスト
  • •スタイルの不一致: ファイルのスタイルと一致しないその他すべての不自然なコード

分析プロセス（拡張思考を使用）

以下について深く考察します：

  1. •アーキテクチャ: これは全体設計に適合しているか？アーキテクチャ上の懸念はないか？
  2. •エッジケース: 何が問題になる可能性があるか？どのような入力がこれを壊すか？
  3. •パフォーマンス: 非効率性はないか？より良いアルゴリズムはあるか？
  4. •保守性: 6ヶ月後も理解しやすいか？
  5. •セキュリティ: 脆弱性はないか？入力検証が必要か？
  6. •テスト: テストは包括的か？Khorivkovの原則に従っているか？
  7. •シンプルさ: これはもっとシンプルにできるか？不要な複雑さはないか？
  8. •AIコードのスラップ（不要生成物）: AI特有の不自然なコードが含まれていないか？

出力フォーマット

言語設定: レビューの出力は すべて日本語 で行ってください。

以下のセクションで構造化されたレビューを提供してください：

📋 概要

  • •変更内容の簡単な要約
  • •全体的な評価（問題なし / 改善が必要 / 問題あり）

🏗️ アーキテクチャとデザイン

  • •高レベルの設計決定
  • •プロジェクトアーキテクチャとの整合性
  • •潜在的なアーキテクチャ上の懸念

✨ コード品質

  • •スタイルと可読性
  • •言語固有のベストプラクティスへの準拠
  • •"Less is More" 原則への準拠
  • •AIコードのスラップ（不要生成物）の検出
  • •具体的な改善点

🧪 テスト戦略（テストが含まれる場合）

  • •Khorivkovの4つの柱に対する評価
  • •テストカバレッジの評価
  • •AAAパターンの使用
  • •モック戦略（適切か？）
  • •テスト改善の提案

💡 具体的な提案

各提案を以下の形式で記述：

code
[優先度: 高/中/低]
**場所**: file_path:line_number
**問題**: 問題の説明
**提案**: 該当する場合はコード例を含む具体的な改善策
**理由**: これが重要な理由

🔒 セキュリティとパフォーマンス

  • •セキュリティ脆弱性
  • •パフォーマンスのボトルネック
  • •外部APIのレート制限考慮（該当する場合）
  • •リソース管理

✅ まとめ

  • •主な強み
  • •クリティカルな問題（もしあれば）
  • •優先順位付けされたアクション項目

手順:

  1. •検出されたモードを使用してレビューするコードを収集
  2. •プロジェクトのコンテキスト（CLAUDE.md、package.jsonなど）を確認
  3. •拡張思考を使用して徹底的に分析
  4. •プロジェクト固有の基準とこのレビュー基準を適用
  5. •例を含む実行可能で具体的なフィードバックを提供
  6. •建設的でありながら正直に - 実際の問題を指摘
  7. •現在の機能性と将来の保守性の両方を考慮

レビュー完了後のアクション

レビューレポートを提供した後、自動的に修正作業を開始してください：

1. 修正タスクの作成

  • •TodoWriteツールを使用して、レビューで指摘したすべての問題を修正タスクとして登録
  • •優先度（高/中/低）を明確に設定
  • •各タスクには具体的な修正内容を記載

2. 修正作業の実施

以下の順序で修正を進めます：

  • •優先度High: クリティカルな問題から着手
  • •優先度Medium: 重要だが緊急ではない問題
  • •優先度Low: 細かい改善点

各修正について：

  • •タスクを in_progress に変更してから作業開始
  • •該当ファイルを編集（Editツール使用）
  • •修正完了後、タスクを completed にマーク
  • •次のタスクに進む

3. テストの実行

修正作業中は適宜テストを実行：

  • •package.jsonの test スクリプトがある場合は実行
  • •リンター/フォーマッター（lint, check, formatなど）がある場合は実行
  • •ビルドスクリプト（build）がある場合は実行
  • •プロジェクト固有のチェックコマンドがあれば実行

4. 修正の方針

  • •段階的な修正: 1つの問題を完全に修正してから次へ
  • •明確な説明: 各修正で何を変更したかを簡潔に説明
  • •テストの維持: 既存のテストが壊れないよう注意
  • •破壊的変更の場合: 特に慎重に対応し、必要に応じてユーザーに確認
    • •例: 公開APIの変更、関数シグネチャの変更、既存テストの削除、データ構造の変更

5. 修正完了後の報告

すべての修正タスクが完了したら：

  • •修正内容の要約を提供
  • •テスト結果を共有
  • •残っている課題や今後の改善提案があれば言及

Review: $ARGUMENTS