zhongwei/gh-masseater-claude-code-plugin-mutils

Fork 0

Files

Zhongwei Li efb1fa136d Initial commit

2025-11-30 08:39:27 +08:00

6.6 KiB

Raw Permalink Blame History

作成した成果物に対して厳格なセルフレビューを実施します

作成したばかりの成果物を見直して、良い点と問題点を洗い出してください。

重要: 「この程度なら良いだろう」という甘えは一切許しません。厳格に自己反省を繰り返しながらセルフレビューを実施してください。

$ARGUMENTS

実施手順

1. レビュー対象の特定

AskUserQuestionツールでレビューモードを質問：

question: 「どのモードでレビューしますか？」
header: 「レビューモード」
デフォルト: 変更差分モード

選択肢：

「変更差分モード（デフォルト）」: git diffとgit diff --stagedで変更されたファイルを対象
「ファイル指定モード」: 引数で指定されたファイルパスを対象

変更差分モードの場合:

git diff --name-onlyとgit diff --staged --name-onlyで変更ファイルを取得
変更されたファイルをすべて対象とする

ファイル指定モードの場合:

引数で指定されたファイルパスを対象とする
引数がない場合は、AskUserQuestionツールでファイルを選択させる（最大4つ）

2. レビューの実施

良い点の洗い出し

客観的に優れている点を具体的に列挙：

設計・アーキテクチャ（単一責任、適切な抽象化、既存パターンとの整合性）
実装品質（可読性、命名、関数型スタイル、エラーハンドリング）
型安全性（any型の不使用、適切な型定義）
テスト（主要ケースのカバー）
ドキュメント（必要なコメント）

問題点の洗い出し（厳格に）

些細な問題も見逃さず指摘：

重大な問題（即座に修正が必要）:

any型の使用（絶対禁止）
場当たり的な対応（「一時的」「とりあえず」「一旦」「ひとまず」「可能性」という表現）
過剰な抽象化（不要なインターフェースや抽象クラス）
循環依存、密結合な設計

改善が望ましい点:

重複コード（既存実装の未確認）
既存ライブラリの未活用
命令型の配列操作（array.push()など、map/filterで書けないか）
不必要なinterfaceの使用（基本的にtypeを使用）
barrel import/export
マジックナンバー/文字列

軽微な改善点:

命名規約、コメント、パフォーマンス、セキュリティなど

問題の優先度判断基準:

重大: システムの安定性・保守性に直接影響、技術的負債となる（any型、場当たり的対応、設計上の欠陥）
改善: コード品質に影響、将来的に問題となる可能性（重複、未活用、非効率な実装）
軽微: 一貫性・可読性に影響、すぐに問題とはならない（命名、コメント）

3. レビュー結果の報告

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 セルフレビュー結果
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

対象: {ファイルパス}
総合評価: {✅ 高品質 / ⚠️ 改善の余地あり / ❌ 重大な問題あり}

## 良い点 ✅
- {具体的な良い点}

## 問題点 ⚠️❌

### 重大（{件数}件）
1. **{カテゴリ}**: {説明}（場所: {パス}:{行}）

### 改善（{件数}件）
1. **{カテゴリ}**: {説明}（場所: {パス}:{行}）

### 軽微（{件数}件）
1. **{カテゴリ}**: {説明}（場所: {パス}:{行}）

## 自己反省 🔥
{場当たり的な対応があれば50文字以上で反省}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

4. 各問題について個別のAskUserQuestionを作成してまとめて質問

見つかった問題について、各問題ごとに個別のAskUserQuestionを用意し、1つのメッセージでまとめて質問してください。

AskUserQuestionツールの制約: 1回のツール呼び出しで最大4問まで

手順:

見つかった全問題（重大 → 改善 → 軽微の順）をリストアップ
各問題について、具体的な修正方法の対応方針案を考える
問題を最大4問ずつのグループに分割
各グループについて、1つのメッセージでAskUserQuestionツールを実行

各質問の形式:

question: 「{問題の説明}（場所: {パス}:{行}）この問題にどう対応しますか？」
header: 「{問題カテゴリ}」（例: "any型使用", "重複コード"）
multiSelect: false

選択肢の作り方: 各選択肢のlabelに具体的な対応方針案を書く。必ず「対応しない」選択肢も含める。

例（any型使用の問題の場合）:

label: "型推論を使用して置き換える" description: "any型を削除し、TypeScriptの型推論に任せる"
label: "明示的な型定義を追加する" description: "適切な型を定義してany型を置き換える"
label: "unknown型に置き換えて型ガードを追加" description: "any型をunknown型に変更し、型ガードで安全性を確保"
label: "対応しない" description: "この問題は許容範囲として対応しない"

例（重複コードの問題の場合）:

label: "共通関数として抽出する" description: "重複部分をユーティリティ関数として抽出"
label: "高階関数でパターンを抽象化する" description: "共通パターンを高階関数として実装"
label: "対応しない" description: "この程度の重複は許容範囲として対応しない"

重要:

labelは必ず具体的な修正方法にすること
複数の対応方針案を提示し、ユーザーに選ばせる

5. Todoタスクの作成

ユーザーが対応方針を選択したら、TodoWriteツールで修正タスクを作成：

content: 「{選択された対応方針}」（例: 「型推論を使用してany型を置き換える」）
activeForm: 「{選択された対応方針}中」（例: 「型推論を使用してany型を置き換え中」）
status: "pending"
優先度順（重大 → 改善 → 軽微）に並べる

重要な注意事項

絶対に甘えを許さない: 「この程度なら良いだろう」は禁止
場当たり的な対応の検出: 「一時的」「とりあえず」「一旦」「ひとまず」「可能性」が見つかったら50文字以上の自己反省文を記述

6.6 KiB Raw Permalink Blame History Unescape Escape