Initial commit
This commit is contained in:
Zhongwei Li
12
.claude-plugin/plugin.json
Normal file
12
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,12 @@
|
||||
{
|
||||
"name": "mutils",
|
||||
"description": "汎用utilityコマンド集（issue計画、コミット整理、多角的視点分析など）",
|
||||
"version": "0.1.0",
|
||||
"author": {
|
||||
"name": "masseater",
|
||||
"email": "zhongweili@tubi.tv"
|
||||
},
|
||||
"commands": [
|
||||
"./commands"
|
||||
]
|
||||
}
|
||||
102
commands/issue-plan.md
Normal file
102
commands/issue-plan.md
Normal file
@@ -0,0 +1,102 @@
|
||||
# GitHub IssueのURLまたは番号から内容を取得し、実装計画を立案します
|
||||
|
||||
GitHub Issueの内容を取得し、詳細な実装計画を立案してください。
|
||||
|
||||
## 実行手順
|
||||
|
||||
### 1. Issue情報の取得
|
||||
|
||||
引数として渡されたIssue番号またはURLから情報を取得します。
|
||||
|
||||
- **Issue番号の場合**: `gh issue view <番号> --json title,comments,body,labels,assignees,milestone`
|
||||
- **URLの場合**: URLから番号を抽出して取得
|
||||
|
||||
### 2. Issue内容の分析
|
||||
|
||||
取得したIssue情報から以下を分析してください:
|
||||
|
||||
- **目的**: このIssueで達成すべきゴールは何か
|
||||
- **要件**: 必須要件とオプション要件の整理
|
||||
- **制約条件**: 技術的制約、期限、依存関係など
|
||||
- **影響範囲**: 変更が及ぶファイル・モジュールの推定
|
||||
|
||||
### 3. 既存コードベースの調査
|
||||
|
||||
実装に関連する既存コードを調査してください:
|
||||
|
||||
- 類似機能の実装パターンを確認
|
||||
- 変更が必要なファイルを特定
|
||||
- 使用すべき既存ライブラリ・ユーティリティを確認
|
||||
- テストの既存パターンを確認
|
||||
|
||||
**重要**: 必ず既存実装を確認してから新規実装を検討すること
|
||||
|
||||
### 4. 実装計画の立案
|
||||
|
||||
以下の構造で実装計画を作成してください:
|
||||
|
||||
#### 4.1 概要
|
||||
- Issueの要約
|
||||
- 実装方針の概要
|
||||
|
||||
#### 4.2 タスク分解
|
||||
実装を具体的なタスクに分解します:
|
||||
|
||||
1. **調査・設計フェーズ**
|
||||
- 必要な技術調査
|
||||
- 設計判断が必要な項目
|
||||
|
||||
2. **実装フェーズ**
|
||||
- ファイル・モジュールごとの実装タスク
|
||||
- 優先度と依存関係を明記
|
||||
|
||||
3. **テストフェーズ**
|
||||
- ユニットテスト
|
||||
- 統合テスト
|
||||
- E2Eテスト（必要な場合）
|
||||
|
||||
4. **品質チェックフェーズ**
|
||||
- 型チェック (`pnpm typecheck:all`)
|
||||
- Lint (`pnpm lint`)
|
||||
- ビルド確認 (`pnpm build`)
|
||||
|
||||
#### 4.3 技術的考慮事項
|
||||
- 使用する技術・ライブラリ
|
||||
- アーキテクチャ上の判断
|
||||
- パフォーマンスへの影響
|
||||
- セキュリティ上の注意点
|
||||
|
||||
#### 4.4 リスクと対策
|
||||
- 想定されるリスク
|
||||
- 各リスクへの対策
|
||||
|
||||
### 5. TodoListの作成
|
||||
|
||||
TodoWriteツールを使用して、実装タスクをTodoListとして登録してください。
|
||||
タスクは以下の形式で:
|
||||
- content: 実施すべきタスク（命令形）
|
||||
- activeForm: 実施中の状態（進行形）
|
||||
- status: pending
|
||||
|
||||
### 6. ユーザーへの確認
|
||||
|
||||
計画内容をユーザーに提示し、以下を確認してください:
|
||||
- この計画で進めて良いか
|
||||
- 優先度や順序の調整が必要か
|
||||
- 追加で考慮すべき点はないか
|
||||
|
||||
## 出力形式
|
||||
|
||||
計画書はMarkdown形式で、見やすく構造化して出力してください。
|
||||
|
||||
## 注意事項
|
||||
|
||||
- `any`型の使用は厳禁
|
||||
- 場当たり的な対応は禁止（「一時的」「とりあえず」等の表現は使わない）
|
||||
- 根本的な解決を目指す
|
||||
- 既存の実装パターンを必ず確認する
|
||||
- プライドを持って設計を行う
|
||||
|
||||
---
|
||||
|
||||
Issue: $ARGUMENTS
|
||||
41
commands/multi-angle-perspectives.md
Normal file
41
commands/multi-angle-perspectives.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# 一般的・保守的・独創的な3つの観点からそれぞれ2つずつ提案を生成します
|
||||
|
||||
以下のテーマについて、3つの異なる観点からそれぞれ2つずつ、合計6つの提案を行ってください。
|
||||
|
||||
## 提案の観点
|
||||
|
||||
### 1. 一般的な観点（Standard Approach）
|
||||
- 広く採用されている標準的な方法
|
||||
- 実績があり、多くの人が理解しやすいアプローチ
|
||||
- ドキュメントやコミュニティサポートが充実している選択肢
|
||||
|
||||
### 2. 保守的な観点（Conservative Approach）
|
||||
- リスクを最小限に抑える安全な方法
|
||||
- 既存システムへの影響が少ない選択肢
|
||||
- 段階的に導入でき、後戻りしやすいアプローチ
|
||||
- 長期的な保守性とメンテナンス性を重視
|
||||
|
||||
### 3. 独創的な観点（Creative Approach）
|
||||
- 革新的で新しいアプローチ
|
||||
- 従来の方法にとらわれない発想
|
||||
- パフォーマンスや効率を大幅に改善する選択肢
|
||||
- 最新技術やトレンドを活用した方法
|
||||
|
||||
## 出力形式
|
||||
|
||||
各提案について以下を含めてください：
|
||||
- **提案内容**：具体的な実装方法や選択肢
|
||||
- **メリット**：この方法の利点
|
||||
- **デメリット**：考慮すべき欠点やトレードオフ
|
||||
- **適用場面**：どのような状況で特に有効か
|
||||
|
||||
## 比較表
|
||||
|
||||
最後に、6つの提案を以下の軸で比較する表を作成してください：
|
||||
- 実装難易度（1-5）
|
||||
- リスク（1-5）
|
||||
- パフォーマンス期待値（1-5）
|
||||
- 保守性（1-5）
|
||||
- 革新性（1-5）
|
||||
|
||||
$ARGUMENTS
|
||||
108
commands/organize-commits.md
Normal file
108
commands/organize-commits.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# 現在の変更を関心ごと単位で分析し、レビューしやすい論理的なコミットに整理します
|
||||
|
||||
# 関心ごと単位でのコミット整理
|
||||
|
||||
現在のブランチの変更内容を分析し、レビュアーが理解しやすいように関心ごと単位で論理的なコミットに整理してください。
|
||||
|
||||
## 実行手順
|
||||
|
||||
### 1. 現在の状態確認
|
||||
- `git status`で変更ファイル一覧を取得
|
||||
- `git diff`で未ステージの変更を確認
|
||||
- `git diff --staged`でステージ済みの変更を確認
|
||||
- デフォルトブランチを確認: `git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/@@'`
|
||||
- 取得できない場合は`git remote show origin | grep 'HEAD branch' | awk '{print $NF}'`で確認
|
||||
|
||||
### 2. 変更内容の分析と分類
|
||||
以下の観点で変更をグループ化：
|
||||
|
||||
#### 関心ごとの分類基準
|
||||
- **機能追加**: 新しい機能の実装
|
||||
- **バグ修正**: 既存のバグの修正
|
||||
- **リファクタリング**: コードの改善（動作は変わらない）
|
||||
- **スタイル調整**: フォーマット、インデント、空白の調整
|
||||
- **型定義**: TypeScriptの型定義の追加・修正
|
||||
- **設定変更**: 設定ファイル（tsconfig, package.json等）の変更
|
||||
- **依存関係**: パッケージの追加・更新・削除
|
||||
- **テスト**: テストコードの追加・修正
|
||||
- **ドキュメント**: README、コメント等の更新
|
||||
- **ビルド/CI**: ビルドツール、CI/CD設定の変更
|
||||
|
||||
### 3. コミット計画の提示
|
||||
```
|
||||
📊 変更内容の分析結果
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
合計: X ファイル変更
|
||||
|
||||
🎯 推奨コミット構成:
|
||||
|
||||
[1] feat: [機能の説明]
|
||||
影響ファイル:
|
||||
- src/components/NewFeature.tsx
|
||||
- src/hooks/useNewFeature.ts
|
||||
|
||||
[2] fix: [バグ修正の説明]
|
||||
影響ファイル:
|
||||
- src/utils/calculation.ts
|
||||
|
||||
[3] refactor: [リファクタリング内容]
|
||||
影響ファイル:
|
||||
- src/components/OldComponent.tsx
|
||||
|
||||
[4] chore: [その他の変更]
|
||||
影響ファイル:
|
||||
- package.json
|
||||
- tsconfig.json
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
### 4. 実行確認
|
||||
ユーザーに以下を確認：
|
||||
- 提案したコミット構成でよいか
|
||||
- コミットメッセージの修正が必要か
|
||||
- 特定のファイルの所属グループを変更したいか
|
||||
|
||||
### 5. コミットの実行
|
||||
承認後、以下の手順で実行：
|
||||
|
||||
1. 全ての変更を一旦アンステージ: `git reset`
|
||||
2. 各グループごとに：
|
||||
- 関連ファイルをステージング: `git add [files]`
|
||||
- 意味のあるコミットメッセージでコミット
|
||||
- Conventional Commitsフォーマットを使用
|
||||
|
||||
### コミットメッセージのフォーマット
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
||||
<body>
|
||||
|
||||
<footer>
|
||||
```
|
||||
|
||||
**Type**:
|
||||
- feat: 新機能
|
||||
- fix: バグ修正
|
||||
- docs: ドキュメントのみの変更
|
||||
- style: コードの意味に影響しない変更
|
||||
- refactor: バグ修正や機能追加を伴わないコード変更
|
||||
- perf: パフォーマンス改善
|
||||
- test: テストの追加・修正
|
||||
- chore: ビルドプロセスやツールの変更
|
||||
|
||||
### 6. 最終確認
|
||||
- 確認したデフォルトブランチを使用して：
|
||||
- `git log --oneline [デフォルトブランチ]..HEAD`でデフォルトブランチからの差分コミットを表示
|
||||
- `git diff [デフォルトブランチ]...HEAD --stat`で変更ファイルの統計を確認
|
||||
- 各コミットが独立してビルド可能か確認
|
||||
- レビュアーの視点で理解しやすいか確認
|
||||
|
||||
## 注意事項
|
||||
- 一つのコミットは一つの論理的な変更単位にする
|
||||
- コミットメッセージは変更の「なぜ」を説明する
|
||||
- 大きすぎるコミットは避ける（理想は100行以下の変更）
|
||||
- 関連性の低い変更を同じコミットに含めない
|
||||
- WIPコミットは作らず、完成した変更のみコミット
|
||||
- デフォルトブランチは必ず動的に確認して使用する
|
||||
|
||||
$ARGUMENTS
|
||||
147
commands/self-review.md
Normal file
147
commands/self-review.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# 作成した成果物に対して厳格なセルフレビューを実施します
|
||||
|
||||
作成したばかりの成果物を見直して、良い点と問題点を洗い出してください。
|
||||
|
||||
**重要**: 「この程度なら良いだろう」という甘えは一切許しません。厳格に自己反省を繰り返しながらセルフレビューを実施してください。
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## 実施手順
|
||||
|
||||
### 1. レビュー対象の特定
|
||||
|
||||
**AskUserQuestionツール**でレビューモードを質問：
|
||||
- question: 「どのモードでレビューしますか？」
|
||||
- header: 「レビューモード」
|
||||
- デフォルト: 変更差分モード
|
||||
|
||||
選択肢：
|
||||
- 「変更差分モード（デフォルト）」: `git diff`と`git diff --staged`で変更されたファイルを対象
|
||||
- 「ファイル指定モード」: 引数で指定されたファイルパスを対象
|
||||
|
||||
**変更差分モードの場合**:
|
||||
1. `git diff --name-only`と`git diff --staged --name-only`で変更ファイルを取得
|
||||
2. 変更されたファイルをすべて対象とする
|
||||
|
||||
**ファイル指定モードの場合**:
|
||||
1. 引数で指定されたファイルパスを対象とする
|
||||
2. 引数がない場合は、**AskUserQuestionツール**でファイルを選択させる（最大4つ）
|
||||
|
||||
### 2. レビューの実施
|
||||
|
||||
#### 良い点の洗い出し
|
||||
客観的に優れている点を具体的に列挙：
|
||||
- 設計・アーキテクチャ（単一責任、適切な抽象化、既存パターンとの整合性）
|
||||
- 実装品質（可読性、命名、関数型スタイル、エラーハンドリング）
|
||||
- 型安全性（`any`型の不使用、適切な型定義）
|
||||
- テスト（主要ケースのカバー）
|
||||
- ドキュメント（必要なコメント）
|
||||
|
||||
#### 問題点の洗い出し（厳格に）
|
||||
些細な問題も見逃さず指摘：
|
||||
|
||||
**重大な問題（即座に修正が必要）**:
|
||||
- `any`型の使用（絶対禁止）
|
||||
- 場当たり的な対応（「一時的」「とりあえず」「一旦」「ひとまず」「可能性」という表現）
|
||||
- 過剰な抽象化（不要なインターフェースや抽象クラス）
|
||||
- 循環依存、密結合な設計
|
||||
|
||||
**改善が望ましい点**:
|
||||
- 重複コード（既存実装の未確認）
|
||||
- 既存ライブラリの未活用
|
||||
- 命令型の配列操作（`array.push()`など、map/filterで書けないか）
|
||||
- 不必要な`interface`の使用（基本的に`type`を使用）
|
||||
- barrel import/export
|
||||
- マジックナンバー/文字列
|
||||
|
||||
**軽微な改善点**:
|
||||
- 命名規約、コメント、パフォーマンス、セキュリティなど
|
||||
|
||||
**問題の優先度判断基準**:
|
||||
- **重大**: システムの安定性・保守性に直接影響、技術的負債となる（any型、場当たり的対応、設計上の欠陥）
|
||||
- **改善**: コード品質に影響、将来的に問題となる可能性（重複、未活用、非効率な実装）
|
||||
- **軽微**: 一貫性・可読性に影響、すぐに問題とはならない（命名、コメント）
|
||||
|
||||
### 3. レビュー結果の報告
|
||||
|
||||
```markdown
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
📋 セルフレビュー結果
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
対象: {ファイルパス}
|
||||
総合評価: {✅ 高品質 / ⚠️ 改善の余地あり / ❌ 重大な問題あり}
|
||||
|
||||
## 良い点 ✅
|
||||
- {具体的な良い点}
|
||||
|
||||
## 問題点 ⚠️❌
|
||||
|
||||
### 重大（{件数}件）
|
||||
1. **{カテゴリ}**: {説明}（場所: {パス}:{行}）
|
||||
|
||||
### 改善（{件数}件）
|
||||
1. **{カテゴリ}**: {説明}（場所: {パス}:{行}）
|
||||
|
||||
### 軽微（{件数}件）
|
||||
1. **{カテゴリ}**: {説明}（場所: {パス}:{行}）
|
||||
|
||||
## 自己反省 🔥
|
||||
{場当たり的な対応があれば50文字以上で反省}
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
### 4. 各問題について個別のAskUserQuestionを作成してまとめて質問
|
||||
|
||||
見つかった問題について、**各問題ごとに個別のAskUserQuestion**を用意し、**1つのメッセージでまとめて質問**してください。
|
||||
|
||||
**AskUserQuestionツールの制約**: 1回のツール呼び出しで最大4問まで
|
||||
|
||||
**手順**:
|
||||
1. 見つかった全問題（重大 → 改善 → 軽微の順）をリストアップ
|
||||
2. 各問題について、具体的な修正方法の対応方針案を考える
|
||||
3. 問題を最大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文字以上の自己反省文を記述
|
||||
57
plugin.lock.json
Normal file
57
plugin.lock.json
Normal file
@@ -0,0 +1,57 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:masseater/claude-code-plugin:mutils",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "aa174261193d6c31449dd0c5b638ef684a62e510",
|
||||
"treeHash": "75332e2157d9186324e1da6f05b595b3ce2ebaa5fd6ec0103567f499f77c5be7",
|
||||
"generatedAt": "2025-11-28T10:27:02.089268Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "mutils",
|
||||
"description": "汎用utilityコマンド集（issue計画、コミット整理、多角的視点分析など）",
|
||||
"version": "0.1.0"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "ddbb5a620be43bbd78cfca69c0cd79ab0fe2218391973b2e5a9a9c690344201a"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "155c94aeb8734e8b53a893f7044befffae37cc473b090ccb7a3abe0267ea9c87"
|
||||
},
|
||||
{
|
||||
"path": "commands/organize-commits.md",
|
||||
"sha256": "299e381b6e4ffeadb9ca4fb3b59ac7891206a82c178e71f3414adc1e138efe9f"
|
||||
},
|
||||
{
|
||||
"path": "commands/issue-plan.md",
|
||||
"sha256": "fe76e773e5361c24bad3d5f856cf3800c08a0b89365e204273e182af9737b036"
|
||||
},
|
||||
{
|
||||
"path": "commands/self-review.md",
|
||||
"sha256": "dd99696875d0dfcb295a2fc858ac4d6ddc263e5b3d4450b195ce61650ad72d67"
|
||||
},
|
||||
{
|
||||
"path": "commands/multi-angle-perspectives.md",
|
||||
"sha256": "a2b87d3061929aabd73e5605fcdbed53b85763920dab15b05795d6a226c68357"
|
||||
}
|
||||
],
|
||||
"dirSha256": "75332e2157d9186324e1da6f05b595b3ce2ebaa5fd6ec0103567f499f77c5be7"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user