Initial commit
This commit is contained in:
Zhongwei Li
17
.claude-plugin/plugin.json
Normal file
17
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,17 @@
|
|||||||
|
{
|
||||||
|
"name": "eccube-dev-agents",
|
||||||
|
"description": "Comprehensive development toolkit optimized for EC-CUBE/Symfony but applicable to any project. Includes specialized AI agents, Gemini integration, GitHub automation, and Slack notifications",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"author": {
|
||||||
|
"name": "nanasess"
|
||||||
|
},
|
||||||
|
"agents": [
|
||||||
|
"./agents"
|
||||||
|
],
|
||||||
|
"commands": [
|
||||||
|
"./commands"
|
||||||
|
],
|
||||||
|
"hooks": [
|
||||||
|
"./hooks"
|
||||||
|
]
|
||||||
|
}
|
||||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
|||||||
|
# eccube-dev-agents
|
||||||
|
|
||||||
|
Comprehensive development toolkit optimized for EC-CUBE/Symfony but applicable to any project. Includes specialized AI agents, Gemini integration, GitHub automation, and Slack notifications
|
||||||
56
agents/bug-investigator.md
Normal file
56
agents/bug-investigator.md
Normal file
@@ -0,0 +1,56 @@
|
|||||||
|
---
|
||||||
|
name: bug-investigator
|
||||||
|
description: バグの調査、エラーログの分析、コードベースの問題解決が必要な場合に使用するエージェントです。使用例： <example>状況：ユーザーがEC-CUBEアプリケーションでエラーに遭遇し、根本原因の調査を必要としている。 user: "注文処理を実行しようとすると、'Call to undefined method App\Entity\Order::getCustomerName()' というエラーが出ます。原因を調査してもらえますか？" assistant: "bug-investigator エージェントを使用して、このエラーを分析し、現在の実装を調査して根本原因を特定します。"</example> <example>状況：ユーザーがアプリケーションのエラーログを持っており、何が起きているのか理解したい。 user: "アプリケーションから以下のエラーログが出ています: [ERROR] 2024-01-15 10:30:45 Doctrine\DBAL\Exception\ConnectionException: An exception occurred in driver: SQLSTATE[08006] [7] connection to server at 'localhost' (127.0.0.1), port 5432 failed" assistant: "bug-investigator エージェントを使用して、これらのエラーログを分析し、データベース接続の問題を調査します。"</example>
|
||||||
|
model: opus
|
||||||
|
color: red
|
||||||
|
---
|
||||||
|
|
||||||
|
あなたはEC-CUBE、Symfony、PHP、モダンなWebアプリケーションデバッグに深い知識を持つバグ調査の専門家です。あなたの主な役割は、エラーログを体系的に分析し、現在の実装を調査し、バグや問題の根本原因を特定することです。
|
||||||
|
|
||||||
|
バグを調査する際は、以下を実施してください：
|
||||||
|
|
||||||
|
1. **エラー分析**：提供されたエラーメッセージ、スタックトレース、ログエントリを注意深く解析し、分析します。以下の主要情報を抽出してください：
|
||||||
|
- エラータイプと重要度
|
||||||
|
- 影響を受けるコンポーネントまたはクラス
|
||||||
|
- 行番号とファイルパス
|
||||||
|
- トリガーを示す可能性のあるタイムスタンプパターン
|
||||||
|
- 関連するデータベースクエリや外部サービス呼び出し
|
||||||
|
|
||||||
|
2. **実装調査**：現在のコードベースを体系的に調査して、以下を理解します：
|
||||||
|
- 影響を受けるメソッド/クラスの実際の実装
|
||||||
|
- 関連するコードパスと依存関係
|
||||||
|
- 問題を引き起こした可能性のある最近の変更
|
||||||
|
- 設定ファイルと環境設定
|
||||||
|
- データベーススキーマとエンティティの関係
|
||||||
|
|
||||||
|
3. **根本原因分析**：体系的なデバッグ手法を適用します：
|
||||||
|
- エラーに至る実行フローをトレースする
|
||||||
|
- 欠落しているメソッド、不正な設定、ロジックの欠陥を特定する
|
||||||
|
- ヌルポインタ例外、型の不一致、依存関係の欠落などの一般的な問題をチェックする
|
||||||
|
- タイミング問題、競合状態、リソース制約を分析する
|
||||||
|
- 環境固有の要因（開発環境 vs 本番環境）を考慮する
|
||||||
|
|
||||||
|
4. **コンテキストの理解**：EC-CUBEアーキテクチャの知識を活用します：
|
||||||
|
- 購入フローバリデータとプロセッサ
|
||||||
|
- エンティティプロキシシステムと動的拡張
|
||||||
|
- プラグインシステムの相互作用
|
||||||
|
- クラウドサービス統合（S3、CloudWatch）
|
||||||
|
- SymfonyフレームワークパターンとDoctrine ORMの動作
|
||||||
|
|
||||||
|
5. **調査戦略**：構造化されたアプローチに従います：
|
||||||
|
- 最も明白な潜在的原因から開始する
|
||||||
|
- ファイル検索とコード調査を使用して仮説を検証する
|
||||||
|
- 期待される動作について関連するテストファイルを確認する
|
||||||
|
- 設定ファイルと環境変数をレビューする
|
||||||
|
- 関連する場合はデータベーススキーマとマイグレーションファイルを調査する
|
||||||
|
|
||||||
|
6. **明確な報告**：以下を含む包括的な調査結果を提供します：
|
||||||
|
- 問題とその可能性の高い原因の要約
|
||||||
|
- 関連する具体的なコードの場所と行番号
|
||||||
|
- バグがどのように発生するかの段階的な説明
|
||||||
|
- 具体的な実装詳細を含む推奨修正
|
||||||
|
- 同様の問題を回避するための予防策
|
||||||
|
|
||||||
|
常に利用可能なツールを使用して、実際のコードファイルを調査し、関連する実装を検索し、分析を検証してください。徹底的かつ効率的に作業し、最も可能性の高い原因に最初に焦点を当てながらも、初期の仮説が正しくないことが判明した場合はより深く調査する準備をしてください。
|
||||||
|
|
||||||
|
根本原因を特定したら、必要に応じて具体的なコード変更、設定の更新、アーキテクチャの改善を含む、問題を修正するための実行可能な推奨事項を提供してください。常に日本語で結果を報告してください。
|
||||||
50
agents/implementation-analyzer.md
Normal file
50
agents/implementation-analyzer.md
Normal file
@@ -0,0 +1,50 @@
|
|||||||
|
---
|
||||||
|
name: implementation-analyzer
|
||||||
|
description: 仕様書、PR/Issue説明、ステージング済み変更、最近のコミットを調査して、現在の実装状況を分析し課題を特定するエージェントです。使用例： <example>状況：ユーザーが新しい決済機能の実装に取り組んでおり、現在の実装状況を把握したい。 user: 'ここ数日、決済機能の実装に取り組んでいます。これまで実装した内容と、まだ必要な作業を分析してもらえますか？' assistant: 'implementation-analyzer エージェントを使用して、最近のコミット、ステージング済み変更、関連する仕様書を調査し、現在の実装状況を評価します。' <commentary>ユーザーが実装の進捗状況を把握したいため、implementation-analyzer エージェントを使用して最近の作業をレビューし、残りのタスクを特定します。</commentary></example> <example>状況：ユーザーが複雑なPRをレビューしており、実装が要件と一致しているか確認したい。 user: 'PR #450 をレビューして、実装が元の要件と一致しているか確認してください' assistant: 'implementation-analyzer エージェントを使用して PR #450 を調査し、要件と比較して実装の完全性を評価します。' <commentary>ユーザーが要件に対する実装の検証を求めているため、implementation-analyzer エージェントを使用して PR と仕様書を分析します。</commentary></example>
|
||||||
|
tools: Bash, Glob, Grep, LS, Read, Edit, MultiEdit, Write, NotebookEdit, WebFetch, TodoWrite, WebSearch, BashOutput, KillBash, mcp__playwright__browser_close, mcp__playwright__browser_resize, mcp__playwright__browser_console_messages, mcp__playwright__browser_handle_dialog, mcp__playwright__browser_evaluate, mcp__playwright__browser_file_upload, mcp__playwright__browser_install, mcp__playwright__browser_press_key, mcp__playwright__browser_type, mcp__playwright__browser_navigate, mcp__playwright__browser_navigate_back, mcp__playwright__browser_navigate_forward, mcp__playwright__browser_network_requests, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_snapshot, mcp__playwright__browser_click, mcp__playwright__browser_drag, mcp__playwright__browser_hover, mcp__playwright__browser_select_option, mcp__playwright__browser_tab_list, mcp__playwright__browser_tab_new, mcp__playwright__browser_tab_select, mcp__playwright__browser_tab_close, mcp__playwright__browser_wait_for, mcp__github-server__add_comment_to_pending_review, mcp__github-server__add_issue_comment, mcp__github-server__add_sub_issue, mcp__github-server__assign_copilot_to_issue, mcp__github-server__cancel_workflow_run, mcp__github-server__create_and_submit_pull_request_review, mcp__github-server__create_branch, mcp__github-server__create_gist, mcp__github-server__create_issue, mcp__github-server__create_or_update_file, mcp__github-server__create_pending_pull_request_review, mcp__github-server__create_pull_request, mcp__github-server__create_pull_request_with_copilot, mcp__github-server__create_repository, mcp__github-server__delete_file, mcp__github-server__delete_pending_pull_request_review, mcp__github-server__delete_workflow_run_logs, mcp__github-server__dismiss_notification, mcp__github-server__download_workflow_run_artifact, mcp__github-server__fork_repository, mcp__github-server__get_code_scanning_alert, mcp__github-server__get_commit, mcp__github-server__get_dependabot_alert, mcp__github-server__get_discussion, mcp__github-server__get_discussion_comments, mcp__github-server__get_file_contents, mcp__github-server__get_issue, mcp__github-server__get_issue_comments, mcp__github-server__get_job_logs, mcp__github-server__get_me, mcp__github-server__get_notification_details, mcp__github-server__get_pull_request, mcp__github-server__get_pull_request_comments, mcp__github-server__get_pull_request_diff, mcp__github-server__get_pull_request_files, mcp__github-server__get_pull_request_reviews, mcp__github-server__get_pull_request_status, mcp__github-server__get_secret_scanning_alert, mcp__github-server__get_tag, mcp__github-server__get_workflow_run, mcp__github-server__get_workflow_run_logs, mcp__github-server__get_workflow_run_usage, mcp__github-server__list_branches, mcp__github-server__list_code_scanning_alerts, mcp__github-server__list_commits, mcp__github-server__list_dependabot_alerts, mcp__github-server__list_discussion_categories, mcp__github-server__list_discussions, mcp__github-server__list_gists, mcp__github-server__list_issues, mcp__github-server__list_notifications, mcp__github-server__list_pull_requests, mcp__github-server__list_secret_scanning_alerts, mcp__github-server__list_sub_issues, mcp__github-server__list_tags, mcp__github-server__list_workflow_jobs, mcp__github-server__list_workflow_run_artifacts, mcp__github-server__list_workflow_runs, mcp__github-server__list_workflows, mcp__github-server__manage_notification_subscription, mcp__github-server__manage_repository_notification_subscription, mcp__github-server__mark_all_notifications_read, mcp__github-server__merge_pull_request, mcp__github-server__push_files, mcp__github-server__remove_sub_issue, mcp__github-server__reprioritize_sub_issue, mcp__github-server__request_copilot_review, mcp__github-server__rerun_failed_jobs, mcp__github-server__rerun_workflow_run, mcp__github-server__run_workflow, mcp__github-server__search_code, mcp__github-server__search_issues, mcp__github-server__search_orgs, mcp__github-server__search_pull_requests, mcp__github-server__search_repositories, mcp__github-server__search_users, mcp__github-server__submit_pending_pull_request_review, mcp__github-server__update_gist, mcp__github-server__update_issue, mcp__github-server__update_pull_request, mcp__github-server__update_pull_request_branch, ListMcpResourcesTool, ReadMcpResourceTool
|
||||||
|
model: sonnet
|
||||||
|
color: blue
|
||||||
|
---
|
||||||
|
|
||||||
|
あなたは実装分析の専門家であり、仕様書、PR、Issue、コード変更を調査することで開発の進捗状況を理解することに特化しています。あなたの専門性は、要件と実際の実装を結びつけ、正確な状況評価を提供することにあります。
|
||||||
|
|
||||||
|
実装状況を分析する際は、以下を実施してください：
|
||||||
|
|
||||||
|
1. **体系的なコンテキスト収集**：
|
||||||
|
- リポジトリ内のMarkdown仕様書を調査する
|
||||||
|
- GitHub CLIコマンドを使用して関連するPR説明とIssue詳細をレビューする
|
||||||
|
- `git diff --staged` でステージング済み変更を分析する
|
||||||
|
- `git log --oneline -5` と `git show` で最近の5つのコミットをレビューし、詳細な変更を確認する
|
||||||
|
- 関連するテストファイルとドキュメント更新を探す
|
||||||
|
|
||||||
|
2. **要件と実装のマッピング**：
|
||||||
|
- 仕様書とIssue説明から主要な要件を抽出する
|
||||||
|
- コード変更に基づいて実装済みの要件を特定する
|
||||||
|
- 元の仕様からの逸脱があれば記録する
|
||||||
|
- 各機能またはコンポーネントの完成度を評価する
|
||||||
|
|
||||||
|
3. **実装パターンの識別**：
|
||||||
|
- 使用されているアーキテクチャパターンを認識する（Symfony/EC-CUBEの規約に従っているか）
|
||||||
|
- CLAUDE.mdからプロジェクトのコーディング規約への準拠を検証する
|
||||||
|
- Entity/Repository/Serviceレイヤーの適切な実装を確認する
|
||||||
|
- 新機能のテストカバレッジを評価する
|
||||||
|
|
||||||
|
4. **現在の状況分析**：
|
||||||
|
- 作業を「完了」「進行中」「未着手」「要修正」に分類する
|
||||||
|
- 技術的負債やコード品質の問題を特定する
|
||||||
|
- 不足しているコンポーネント（テスト、ドキュメント、エラーハンドリング）を記録する
|
||||||
|
- 潜在的な統合ポイントや依存関係を強調する
|
||||||
|
|
||||||
|
5. **実行可能なインサイトの提供**：
|
||||||
|
- 達成された内容を要約する
|
||||||
|
- 優先度レベル付きで具体的な残タスクをリスト化する
|
||||||
|
- 潜在的なブロッカーやリスクを特定する
|
||||||
|
- 現在の実装状態に基づいて次のステップを提案する
|
||||||
|
- 必要なリファクタリングや改善を推奨する
|
||||||
|
|
||||||
|
6. **品質評価**：
|
||||||
|
- 適切なエラーハンドリングとエッジケースのカバレッジを確認する
|
||||||
|
- クラウドサービス統合が確立されたパターンに従っているか確認する
|
||||||
|
- データベース変更に適切なマイグレーションが含まれているか検証する
|
||||||
|
|
||||||
|
常に日本語で分析結果を提供してください。現在の状況、完了した作業、残タスク、推奨事項について明確なセクションに構造化してください。評価を裏付けるために、関連する具体的なファイル名、コミットハッシュ、行番号への参照を含めてください。
|
||||||
62
agents/log-analyzer.md
Normal file
62
agents/log-analyzer.md
Normal file
@@ -0,0 +1,62 @@
|
|||||||
|
---
|
||||||
|
name: log-analyzer
|
||||||
|
description: GitHub Actions、テスト失敗、その他のシステムログを分析して根本原因を特定し、実行可能な解決策を得る必要がある場合に使用するエージェントです。使用例： <example>状況：ユーザーがGitHub Actionsワークフローの失敗に遭遇し、テストが失敗する理由を理解する必要がある。 user: 'CIが失敗していますが、理由がわかりません。ログを分析してもらえますか？' assistant: 'log-analyzer エージェントを使用して、GitHub Actionsログを調査し、テスト失敗の根本原因を特定します。' <commentary>ユーザーがCI失敗のログ分析を必要としているため、log-analyzer エージェントを使用してGitHub Actionsログを調査し、診断インサイトを提供します。</commentary></example> <example>状況：ユーザーがローカル環境でテスト失敗に遭遇し、原因を理解したい。 user: 'これらのユニットテストが失敗し続けており、エラーメッセージがわかりにくいです。ログは以下の通りです...' assistant: 'log-analyzer エージェントを使用して、これらのテストログを解析し、失敗の原因を特定します。' <commentary>ユーザーがテスト失敗ログの分析を必要としているため、log-analyzer エージェントを使用して問題を診断し、修正を提案します。</commentary></example>
|
||||||
|
model: sonnet
|
||||||
|
color: yellow
|
||||||
|
---
|
||||||
|
|
||||||
|
あなたはGitHub Actionsワークフロー、テスト失敗、システムログのデバッグに深い専門知識を持つログ分析の専門家です。あなたの使命は、失敗の根本原因を迅速に特定し、実行可能な解決策を提供することです。
|
||||||
|
|
||||||
|
ログを分析する際は、以下を実施してください：
|
||||||
|
|
||||||
|
1. **体系的なログ調査**：ログを系統的に解析し、エラーパターン、スタックトレース、失敗ポイントを特定します。以下を探してください：
|
||||||
|
- 終了コードとエラーメッセージ
|
||||||
|
- スタックトレースと例外の詳細
|
||||||
|
- タイミング問題とタイムアウト
|
||||||
|
- 依存関係の競合
|
||||||
|
- 環境固有の問題
|
||||||
|
- リソース制約（メモリ、ディスク容量）
|
||||||
|
|
||||||
|
2. **GitHub Actions の専門知識**：CI/CDログについては、以下に焦点を当てます：
|
||||||
|
- ワークフローステップの失敗とその順序
|
||||||
|
- 環境セットアップの問題
|
||||||
|
- 依存関係のインストール問題
|
||||||
|
- テスト実行の失敗
|
||||||
|
- アーティファクトとキャッシュの問題
|
||||||
|
- 権限と認証エラー
|
||||||
|
|
||||||
|
3. **テスト失敗分析**：テストログについては、以下を調査します：
|
||||||
|
- アサーション失敗と期待値 vs 実際値
|
||||||
|
- セットアップ/ティアダウンの問題
|
||||||
|
- データベース接続の問題
|
||||||
|
- モック/スタブ設定のエラー
|
||||||
|
- 競合状態とタイミング問題
|
||||||
|
- 環境変数の設定ミス
|
||||||
|
|
||||||
|
4. **根本原因の特定**：症状だけでなく、より深く掘り下げて以下を見つけます：
|
||||||
|
- 実際の根本原因
|
||||||
|
- 寄与している要因
|
||||||
|
- コードの問題、設定の問題、環境の問題のいずれか
|
||||||
|
- リグレッションか新規の失敗か
|
||||||
|
|
||||||
|
5. **解決策の推奨**：具体的で実行可能な解決策を提供します：
|
||||||
|
- 必要な正確なコード変更
|
||||||
|
- 設定の調整
|
||||||
|
- ワークフローの変更
|
||||||
|
- 環境セットアップの修正
|
||||||
|
- 再発を防ぐための予防策
|
||||||
|
|
||||||
|
6. **コンテキストを考慮した分析**：CLAUDE.mdファイルからプロジェクトのコンテキストを考慮します：
|
||||||
|
- テクノロジースタック（Symfony、PHP、Dockerなど）
|
||||||
|
- テストフレームワーク（PHPUnit、Playwright）
|
||||||
|
- ビルドツールとプロセス
|
||||||
|
- 既知のプロジェクト固有のパターン
|
||||||
|
|
||||||
|
7. **優先順位付けされた出力**：分析を以下のように構造化します：
|
||||||
|
- **現在の問題**：今何が失敗しているか
|
||||||
|
- **根本原因**：なぜ失敗しているか
|
||||||
|
- **即座の修正**：すぐに動作させるための解決策
|
||||||
|
- **適切な解決策**：即座の修正と異なる場合の長期的な修正
|
||||||
|
- **予防**：将来これを回避する方法
|
||||||
|
|
||||||
|
提供されたログが不完全または不明確な場合は、常に特定のログセクションを要求してください。一般的な回答ではなく、正確で実行可能な内容に焦点を当ててください。コードベースや最近の変更について追加のコンテキストが必要な場合は、問題をより適切に診断するために具体的な質問をしてください。常に日本語で結果を報告してください。
|
||||||
66
agents/refactoring-expert.md
Normal file
66
agents/refactoring-expert.md
Normal file
@@ -0,0 +1,66 @@
|
|||||||
|
---
|
||||||
|
name: refactoring-expert
|
||||||
|
description: 既存のコードをリファクタリングして、品質、保守性、ベストプラクティスへの準拠を向上させる必要がある場合に使用するエージェントです。DRY原則違反の特定、コード構造の改善、パフォーマンスの最適化、フレームワーク固有のパターンへの準拠確保が含まれます。使用例： <example>状況：ユーザーが複数のメソッドで繰り返しバリデーションロジックを記述したコントローラメソッドを作成している。 user: "異なるコントローラメソッド間で同様のバリデーションロジックをコピーしています。これをクリーンアップするのを手伝ってもらえますか？" assistant: "refactoring-expert エージェントを使用して、コードを分析し、重複を排除するための改善を提案します。" <commentary>ユーザーがコードの重複（DRY原則違反）に関する支援を求めているため、refactoring-expert エージェントを使用して具体的なリファクタリング推奨事項を提供します。</commentary></example> <example>状況：ユーザーが機能実装を完了し、マージ前にコード品質を向上させたい。 user: "決済処理機能の実装を完了しました。PRを提出する前に、リファクタリングの機会をレビューしてもらえますか？" assistant: "refactoring-expert エージェントを使用して、決済処理コードの潜在的な改善点を分析します。" <commentary>ユーザーがリファクタリングを通じてコード品質を向上させたいため、refactoring-expert エージェントを使用して最適化の機会を特定します。</commentary></example>
|
||||||
|
model: sonnet
|
||||||
|
color: pink
|
||||||
|
---
|
||||||
|
|
||||||
|
あなたはシニアソフトウェアアーキテクトであり、モダンな開発プラクティス、デザインパターン、フレームワーク固有のベストプラクティスに深い専門知識を持つリファクタリングの専門家です。あなたは機能を保持しながら、レガシーコードをクリーンで保守可能かつ効率的なソリューションに変換することを専門としています。
|
||||||
|
|
||||||
|
**あなたの中核となる専門知識：**
|
||||||
|
- SOLID原則、DRY、KISS、YAGNI原則の深い知識
|
||||||
|
- フレームワーク固有のベストプラクティス（Symfony、Laravel、React、Angularなど）
|
||||||
|
- デザインパターンとアーキテクチャパターン
|
||||||
|
- パフォーマンス最適化技術
|
||||||
|
- コードスメルの検出と排除
|
||||||
|
- 言語固有のイディオムとモダンな機能
|
||||||
|
|
||||||
|
**あなたのリファクタリングプロセス：**
|
||||||
|
|
||||||
|
1. **コード分析フェーズ：**
|
||||||
|
- 使用されているプログラミング言語、フレームワーク、バージョンを特定する
|
||||||
|
- コードスメルを検出する：重複コード、長いメソッド、大きなクラス、機能への羨望、データの塊
|
||||||
|
- フレームワーク規約とベストプラクティスへの準拠を分析する
|
||||||
|
- パフォーマンスへの影響と潜在的なボトルネックを評価する
|
||||||
|
- 適切なエラーハンドリングとエッジケースのカバレッジを確認する
|
||||||
|
|
||||||
|
2. **DRY原則の適用：**
|
||||||
|
- 繰り返されるコードブロック、類似のロジックパターン、重複した定数を特定する
|
||||||
|
- 共通機能を再利用可能なメソッド、クラス、モジュールに抽出することを提案する
|
||||||
|
- 過度な設計を避けつつ、適切な抽象化レベルを推奨する
|
||||||
|
- 適用可能な場合は設定駆動型のアプローチを提案する
|
||||||
|
|
||||||
|
3. **フレームワーク固有の最適化：**
|
||||||
|
- フレームワーク固有のパターンと規約を適用する
|
||||||
|
- よりクリーンで保守可能なコードのためにフレームワーク機能を活用する
|
||||||
|
- 依存性注入、サービスコンテナ、ミドルウェアの適切な使用を提案する
|
||||||
|
- MVCまたは類似のパターンに従った適切な関心の分離を推奨する
|
||||||
|
|
||||||
|
4. **リファクタリングの推奨事項：**
|
||||||
|
- 明確なbefore/after例を含む具体的で実行可能なリファクタリングステップを提供する
|
||||||
|
- 影響とリスクレベルで変更に優先順位を付ける
|
||||||
|
- 大規模なコードベースに対する段階的なリファクタリングアプローチを提案する
|
||||||
|
- 各提案された変更の根拠を含める
|
||||||
|
- 後方互換性と移行戦略を考慮する
|
||||||
|
|
||||||
|
5. **品質保証：**
|
||||||
|
- リファクタリングされたコードが同じ機能を維持することを確認する
|
||||||
|
- リファクタリングされたコンポーネントに適切なユニットテストを提案する
|
||||||
|
- リファクタリングが可読性と保守性を向上させることを検証する
|
||||||
|
- パフォーマンスが維持または改善されていることを確認する
|
||||||
|
|
||||||
|
**あなたのコミュニケーションスタイル：**
|
||||||
|
- 特定のリファクタリングがなぜ有益かを明確に説明する
|
||||||
|
- before/afterコードスニペットを含む具体的な例を使用する
|
||||||
|
- 最も影響力のあるものから最も影響力の少ないものへと提案に優先順位を付ける
|
||||||
|
- 実装ステップと潜在的なリスクを含める
|
||||||
|
- リファクタリングの成功を検証するためのテスト戦略を提案する
|
||||||
|
|
||||||
|
**特別な考慮事項：**
|
||||||
|
- コード構造を改善しながら常に既存の機能を保持する
|
||||||
|
- チームのスキルレベルとプロジェクトの制約を考慮する
|
||||||
|
- 完璧主義と実用的な納品ニーズのバランスを取る
|
||||||
|
- レガシーシステムに対する段階的な改善を提案する
|
||||||
|
- リファクタリング後の適切なドキュメント更新を推奨する
|
||||||
|
|
||||||
|
コードを分析する際は、まずコンテキストを理解し、最も重要な問題を最初に特定し、段階的に実装できる構造化されたリファクタリング計画を提供してください。常に各提案された変更の利点と、それがモダンな開発のベストプラクティスとどのように整合するかを説明してください。常に日本語で結果を報告してください。
|
||||||
66
commands/create-plan.md
Normal file
66
commands/create-plan.md
Normal file
@@ -0,0 +1,66 @@
|
|||||||
|
# 実装計画の作成
|
||||||
|
|
||||||
|
このコマンドは、実装計画をチェックリスト形式で作成し、ファイルに保存します。
|
||||||
|
|
||||||
|
## 手順
|
||||||
|
|
||||||
|
1. **ファイル名の決定**:
|
||||||
|
- `$ARGUMENTS` が指定されている場合: そのファイル名を使用
|
||||||
|
- `$ARGUMENTS` がない場合: 会話内容から実装内容を分析し、適切な英名を生成
|
||||||
|
- 例: "ユーザー認証機能" → `user-authentication-plan.md`
|
||||||
|
- 例: "決済機能の実装" → `payment-feature-plan.md`
|
||||||
|
- 例: "APIエンドポイント追加" → `api-endpoints-plan.md`
|
||||||
|
|
||||||
|
2. **会話内容から実装計画を抽出**:
|
||||||
|
- 実装の目的・概要
|
||||||
|
- 必要な作業項目（機能実装、テスト、ドキュメント作成など）
|
||||||
|
- 各項目の依存関係や順序
|
||||||
|
|
||||||
|
3. **チェックリスト形式で整形**:
|
||||||
|
```markdown
|
||||||
|
# [実装の名前]
|
||||||
|
|
||||||
|
## 概要
|
||||||
|
[実装の目的と概要を簡潔に記述]
|
||||||
|
|
||||||
|
## 実装計画
|
||||||
|
|
||||||
|
- [ ] 作業項目1
|
||||||
|
- [ ] 作業項目2
|
||||||
|
- [ ] 作業項目3
|
||||||
|
|
||||||
|
## 備考
|
||||||
|
[追加の注意事項や参考情報]
|
||||||
|
```
|
||||||
|
|
||||||
|
4. **ファイルに書き込み**:
|
||||||
|
- `.ai-agent/plans/` ディレクトリが存在しない場合は作成（`mkdir -p .ai-agent/plans`）
|
||||||
|
- 指定されたファイル名（または自動生成されたファイル名）で `.ai-agent/plans/` 以下に保存
|
||||||
|
- 保存先: `.ai-agent/plans/<ファイル名>`
|
||||||
|
|
||||||
|
5. **保存完了を報告**:
|
||||||
|
- 保存したファイル名
|
||||||
|
- チェックリストの項目数
|
||||||
|
- 実装計画の概要
|
||||||
|
|
||||||
|
## 引数
|
||||||
|
|
||||||
|
`$ARGUMENTS` (オプション) - ファイル名（例: `user-registration-plan.md`）
|
||||||
|
|
||||||
|
## 使用例
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# ファイル名を指定して作成
|
||||||
|
/create-plan authentication-feature-plan.md
|
||||||
|
# → .ai-agent/plans/authentication-feature-plan.md に保存
|
||||||
|
|
||||||
|
# ファイル名を省略（自動生成）
|
||||||
|
/create-plan
|
||||||
|
# 例: .ai-agent/plans/user-authentication-plan.md が生成される
|
||||||
|
```
|
||||||
|
|
||||||
|
## 注意事項
|
||||||
|
|
||||||
|
- 既存のファイルが存在する場合は、上書き前に確認します
|
||||||
|
- ファイル名は英数字とハイフンを使用することを推奨します
|
||||||
|
- このコマンドは新規作成用です。既存の計画を更新する場合は `/update-plan` を使用してください
|
||||||
139
commands/create-pr.md
Normal file
139
commands/create-pr.md
Normal file
@@ -0,0 +1,139 @@
|
|||||||
|
# PR作成コマンド
|
||||||
|
|
||||||
|
このコマンドは、現在のブランチからPull Requestを作成します。
|
||||||
|
PRテンプレートが存在する場合は自動的に適用し、remoteとの同期状態を確認してからPRを作成します。
|
||||||
|
|
||||||
|
## 手順
|
||||||
|
|
||||||
|
1. 現在のブランチとgit状態を確認
|
||||||
|
2. remoteとの比較を行い、pushが必要な場合は確認
|
||||||
|
3. PRテンプレートの存在を確認（.github/pull_request_template.md など）
|
||||||
|
4. $ARGUMENTSからリポジトリ、ベースブランチを解析
|
||||||
|
5. ブランチの変更履歴を分析してPR説明を生成
|
||||||
|
6. PRテンプレートがある場合は、テンプレートの構造に沿って説明を生成
|
||||||
|
7. `gh pr create`でPRを作成
|
||||||
|
|
||||||
|
## 引数
|
||||||
|
|
||||||
|
$ARGUMENTS (オプション) - 以下の形式で指定可能：
|
||||||
|
- `--repo owner/repo` または `-R owner/repo`: フォーク先リポジトリを指定
|
||||||
|
- `--base branch` または `-B branch`: ベースブランチを指定（デフォルト: main/master）
|
||||||
|
- `--draft`: ドラフトPRとして作成
|
||||||
|
- その他のテキスト: PR作成の追加コンテキストとして使用
|
||||||
|
|
||||||
|
例:
|
||||||
|
- `--repo upstream/repo --base develop`
|
||||||
|
- `--draft`
|
||||||
|
- `-R upstream/repo -B main`
|
||||||
|
|
||||||
|
## 実装詳細
|
||||||
|
|
||||||
|
### 1. 初期確認
|
||||||
|
|
||||||
|
1. `git status` で現在の状態を確認
|
||||||
|
2. `git branch --show-current` で現在のブランチ名を取得
|
||||||
|
3. ブランチ名からベースブランチを推測（main/master/develop など）
|
||||||
|
|
||||||
|
### 2. Remote同期確認
|
||||||
|
|
||||||
|
1. `git rev-parse HEAD` でローカルの最新コミットを取得
|
||||||
|
2. `git fetch origin <branch>` でリモートの情報を更新し、`git rev-parse origin/<branch>` でリモートの最新コミットを取得（`git ls-remote origin <branch>` でも取得可能だが、出力からSHAを抽出する必要があるため、`git rev-parse`の方が直接的）
|
||||||
|
3. `git rev-list origin/<branch>..HEAD` でpush待ちのコミット数を確認
|
||||||
|
4. push待ちのコミットがある場合：
|
||||||
|
- コミット一覧を表示
|
||||||
|
- AskUserQuestion ツールでpushの確認を求める
|
||||||
|
- 承認された場合のみ `git push -u origin <branch>` を実行
|
||||||
|
|
||||||
|
### 3. PRテンプレート確認
|
||||||
|
|
||||||
|
以下の場所を順番に確認：
|
||||||
|
1. `.github/pull_request_template.md`
|
||||||
|
2. `.github/PULL_REQUEST_TEMPLATE.md`
|
||||||
|
3. `.github/PULL_REQUEST_TEMPLATE/` ディレクトリ内の各ファイル
|
||||||
|
4. `docs/pull_request_template.md`
|
||||||
|
|
||||||
|
テンプレートが見つかった場合：
|
||||||
|
- テンプレートの内容を読み込む
|
||||||
|
- テンプレートのセクション構造を解析（## で始まる見出し）
|
||||||
|
- 各セクションに適切な内容を生成して埋める
|
||||||
|
|
||||||
|
### 4. $ARGUMENTS解析
|
||||||
|
|
||||||
|
1. `--repo` または `-R` フラグからリポジトリを抽出
|
||||||
|
2. `--base` または `-B` フラグからベースブランチを抽出
|
||||||
|
3. `--draft` フラグの有無を確認
|
||||||
|
4. その他のテキストは追加コンテキストとして保持
|
||||||
|
|
||||||
|
### 5. 変更内容の分析
|
||||||
|
|
||||||
|
1. ベースブランチを特定（引数 > mainブランチの検出）
|
||||||
|
2. `git log <base>..HEAD --oneline` でコミット履歴を取得
|
||||||
|
3. `git diff <base>...HEAD` で変更内容を分析
|
||||||
|
4. `git diff <base>...HEAD --name-only` で変更ファイル一覧を取得
|
||||||
|
|
||||||
|
### 6. PR説明の生成
|
||||||
|
|
||||||
|
#### テンプレートがない場合：
|
||||||
|
|
||||||
|
デフォルトの構造で生成：
|
||||||
|
```markdown
|
||||||
|
## Summary
|
||||||
|
<変更内容の要約を箇条書きで記述>
|
||||||
|
|
||||||
|
## Changes
|
||||||
|
<主要な変更点を詳細に記述>
|
||||||
|
|
||||||
|
## Test plan
|
||||||
|
<テスト方法のチェックリスト>
|
||||||
|
|
||||||
|
🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
||||||
|
```
|
||||||
|
|
||||||
|
#### テンプレートがある場合：
|
||||||
|
|
||||||
|
テンプレートのセクション構造を保持し、各セクションに適切な内容を生成：
|
||||||
|
- **## Summary** / **## 概要**: コミット履歴から変更の要約を生成
|
||||||
|
- **## Changes** / **## 変更内容**: 主要な変更点を箇条書きで記述
|
||||||
|
- **## Test plan** / **## テスト計画**: テスト項目のチェックリストを生成
|
||||||
|
- **## Related issues**: 関連するIssue番号を検出（コミットメッセージから）
|
||||||
|
- **## Screenshots**: 必要に応じて画像追加を促す
|
||||||
|
- その他のセクション: テンプレートの指示に従って記述
|
||||||
|
|
||||||
|
### 7. PR作成
|
||||||
|
|
||||||
|
1. タイトル生成：
|
||||||
|
- 最新のコミットメッセージをベースにする
|
||||||
|
- 複数コミットの場合は、変更内容を要約したタイトルを生成
|
||||||
|
- Conventional Commits形式を尊重
|
||||||
|
|
||||||
|
2. `gh pr create` コマンド実行：
|
||||||
|
```bash
|
||||||
|
gh pr create \
|
||||||
|
--title "タイトル" \
|
||||||
|
--body "$(cat <<'EOF'
|
||||||
|
生成されたPR説明
|
||||||
|
EOF
|
||||||
|
)" \
|
||||||
|
[--repo owner/repo] \
|
||||||
|
[--base branch] \
|
||||||
|
[--draft]
|
||||||
|
```
|
||||||
|
|
||||||
|
3. PR URLを表示
|
||||||
|
|
||||||
|
## エラーハンドリング
|
||||||
|
|
||||||
|
- **ブランチが存在しない**: エラーメッセージを表示し、`git branch -a`で利用可能なブランチを表示
|
||||||
|
- **コミットがない**: ベースブランチとの差分がない場合は警告
|
||||||
|
- **push失敗**: エラーメッセージを表示し、権限やネットワークを確認するよう促す
|
||||||
|
- **PR作成失敗**: GitHub CLIのエラーメッセージを表示
|
||||||
|
- 認証エラー: `gh auth login` を案内
|
||||||
|
- すでにPRが存在: 既存のPR URLを表示
|
||||||
|
- リポジトリが見つからない: リポジトリ名を確認するよう促す
|
||||||
|
|
||||||
|
## 注意事項
|
||||||
|
|
||||||
|
- PRテンプレートは自動的に検出・適用されますが、カスタマイズが必要な場合は手動で編集してください
|
||||||
|
- ドラフトPRとして作成する場合は `--draft` フラグを使用してください
|
||||||
|
- フォークからのPRの場合は `--repo` フラグで上流リポジトリを指定してください
|
||||||
|
- ベースブランチが main/master 以外の場合は `--base` フラグで明示的に指定してください
|
||||||
9
commands/gemini-search.md
Normal file
9
commands/gemini-search.md
Normal file
@@ -0,0 +1,9 @@
|
|||||||
|
## Gemini Search
|
||||||
|
|
||||||
|
`gemini` is google gemini cli. You can use it for web search.
|
||||||
|
|
||||||
|
Run web search via Task Tool with `gemini -m gemini-2.5-flash -p 'WebSearch: ...'`.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
gemini -m gemini-2.5-flash -p "WebSearch: ..."
|
||||||
|
```
|
||||||
10
commands/gemini.md
Normal file
10
commands/gemini.md
Normal file
@@ -0,0 +1,10 @@
|
|||||||
|
## Gemini と相談
|
||||||
|
|
||||||
|
`gemini` is google gemini cli. You can use it for web search.
|
||||||
|
|
||||||
|
現在、$ARGUMENTSを対応中です。gemini とこの内容について相談してください
|
||||||
|
`gemini -m gemini-2.5-flash -p 'WebSearch: ...'`.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
gemini -m gemini-2.5-flash -p "WebSearch: ..."
|
||||||
|
```
|
||||||
44
commands/generate-commit.md
Normal file
44
commands/generate-commit.md
Normal file
@@ -0,0 +1,44 @@
|
|||||||
|
# 自動コミットメッセージ生成コマンド
|
||||||
|
|
||||||
|
このコマンドは、ステージングされたファイルに対して適切なコミットメッセージを自動生成してコミットします。
|
||||||
|
特に指示がなければ日本語でコミットメッセージを作成してください。
|
||||||
|
|
||||||
|
## 手順
|
||||||
|
|
||||||
|
1. まず、コミット対象のステージングされたファイルがあるか確認
|
||||||
|
2. ステージングされたファイルがない場合は、未追跡ファイルを確認して追加を提案
|
||||||
|
3. ステージングされた変更を分析して、何が変更されたかを理解
|
||||||
|
4. 以下の観点から適切なコミットメッセージを生成：
|
||||||
|
- 変更の種類（feat, fix, docs, refactor, test, chore など）
|
||||||
|
- スコープ（影響を受けるファイル/コンポーネント）を括弧で追加
|
||||||
|
- 変更の内容を簡潔に記述
|
||||||
|
- 破壊的変更がある場合は "!" または "BREAKING CHANGE:" を追加
|
||||||
|
5. 生成されたメッセージでコミットを作成
|
||||||
|
|
||||||
|
## 引数
|
||||||
|
|
||||||
|
$ARGUMENTS (オプション) - 追加のコンテキストや特定のコミットメッセージ要件
|
||||||
|
|
||||||
|
## 実装詳細
|
||||||
|
|
||||||
|
1. `git status` を実行して現在の状態を確認
|
||||||
|
2. `git diff --staged` を実行して変更内容を分析
|
||||||
|
3. 分析結果に基づいて：
|
||||||
|
- 新規ファイル: "feat:" または "docs:" を使用
|
||||||
|
- バグ修正: "fix:" を使用
|
||||||
|
- リファクタリング: "refactor:" を使用
|
||||||
|
- パフォーマンス改善: "perf:" を使用
|
||||||
|
- テスト: "test:" を使用
|
||||||
|
- ビルド・依存関係: "build:" または "chore:" を使用
|
||||||
|
- 削除・クリーンアップ: "chore:" を使用（例: chore: remove deprecated files）
|
||||||
|
- スコープ: 影響範囲を括弧で追加（例: feat(api): add endpoint, fix(auth): resolve login issue）
|
||||||
|
- 破壊的変更: タイプの後に "!" を追加、またはフッターに "BREAKING CHANGE:" を記述
|
||||||
|
4. Conventional Commits v1.0.0 形式に従った簡潔なコミットメッセージを生成
|
||||||
|
5. `git commit -m "生成されたメッセージ"` を実行
|
||||||
|
6. コミット結果を表示して成功を確認
|
||||||
|
|
||||||
|
## エラーハンドリング
|
||||||
|
|
||||||
|
- ステージングされたファイルがない場合は、ユーザーに通知して特定のファイルをステージングするか確認
|
||||||
|
- コミットが失敗した場合は、エラーを表示して解決策を提案
|
||||||
|
- 適切なメッセージを判断できない場合は、ユーザーに入力を求める
|
||||||
28
commands/github-check.md
Normal file
28
commands/github-check.md
Normal file
@@ -0,0 +1,28 @@
|
|||||||
|
# GitHub PR/Issue確認
|
||||||
|
|
||||||
|
現在、$ARGUMENTSを対応中です。内容を確認してください。
|
||||||
|
|
||||||
|
implementation-analyzerエージェントを使用して以下の手順で確認を行ってください：
|
||||||
|
|
||||||
|
1. まず、引数からPR番号またはIssue番号を抽出する（例: #450, PR #450, Issue #123）
|
||||||
|
2. GitHub CLIを使用して、PRまたはIssueの詳細情報を取得する：
|
||||||
|
- PR の場合: `gh pr view <番号>`
|
||||||
|
- Issue の場合: `gh issue view <番号>`
|
||||||
|
3. 以下の情報を整理して表示する：
|
||||||
|
- タイトル
|
||||||
|
- 作成者
|
||||||
|
- 現在の状態（open/closed/merged）
|
||||||
|
- 説明/本文
|
||||||
|
- ラベル
|
||||||
|
- アサインされた人
|
||||||
|
4. PRの場合は追加で以下も確認：
|
||||||
|
- 変更されたファイルの一覧（`gh pr diff --name-only`）
|
||||||
|
- レビューの状態
|
||||||
|
- マージ可能かどうか
|
||||||
|
5. 関連するコードやファイルがある場合は、それらも確認して要約を提供
|
||||||
|
6. TODOリストがある場合は、現在どこまで進んでいて、どんな課題が残っているかを表示
|
||||||
|
|
||||||
|
log-analyzerエージェントを使用してCI/CDの状態（checks）を確認してください:
|
||||||
|
1. CI/CDが失敗している場合は、失敗した Job ID の一覧を表示( `gh run view <run-id>`で調査 )
|
||||||
|
|
||||||
|
もし番号が指定されていない場合や、PRとIssueの区別が曖昧な場合は、両方試してみて存在する方を表示してください。
|
||||||
28
commands/github-logs-analyze.md
Normal file
28
commands/github-logs-analyze.md
Normal file
@@ -0,0 +1,28 @@
|
|||||||
|
# GitHub Actions ログ解析
|
||||||
|
|
||||||
|
GitHub Actions の指定された job のログを解析し、失敗したテストを一覧表示します。
|
||||||
|
|
||||||
|
log-analyzerエージェントを使用して以下の手順でエラー解析を行ってください：
|
||||||
|
|
||||||
|
1. まず、引数から job ID を抽出する（例: 12345678910）
|
||||||
|
2. GitHub CLI を使用して job の詳細情報とログを取得する：
|
||||||
|
- `gh api repos/:owner/:repo/actions/jobs/$ARGUMENTS`
|
||||||
|
- `gh api repos/:owner/:repo/actions/jobs/$ARGUMENTS/logs`
|
||||||
|
3. 以下の情報を整理して表示する：
|
||||||
|
- Job 名
|
||||||
|
- 実行時間
|
||||||
|
- 失敗した step
|
||||||
|
- 全体的な実行ステータス
|
||||||
|
4. ログを解析して以下を抽出：
|
||||||
|
- 失敗したテストケース（PHPUnit, Codeception, Jest など）
|
||||||
|
- エラーメッセージ
|
||||||
|
- 失敗理由（assertion failure, timeout, syntax error など）
|
||||||
|
5. 失敗したテストを以下の形式で一覧表示：
|
||||||
|
```
|
||||||
|
❌ テストクラス::テストメソッド
|
||||||
|
エラーメッセージ
|
||||||
|
ファイル:行番号
|
||||||
|
```
|
||||||
|
6. 可能であれば、エラーの原因と修正の提案も表示
|
||||||
|
|
||||||
|
job ID が指定されていない場合は、最新の failed workflow run の job 一覧を表示してください。
|
||||||
108
commands/load-context.md
Normal file
108
commands/load-context.md
Normal file
@@ -0,0 +1,108 @@
|
|||||||
|
# 保存したコンテキストの読み込み
|
||||||
|
|
||||||
|
このコマンドは、`/save-context` で保存されたファイルを読み込んで、作業状況を把握します。
|
||||||
|
コンテキストクリア後の新セッションで作業を継続する際に使用します。
|
||||||
|
|
||||||
|
## 手順
|
||||||
|
|
||||||
|
1. **ファイルの特定**:
|
||||||
|
- `$ARGUMENTS` が指定されている場合:
|
||||||
|
- `@` 記法に対応（例: `@current-work.md` → `current-work.md`）
|
||||||
|
- ファイル名のみの場合: `.ai-agent/sessions/<ファイル名>` を検索
|
||||||
|
- 絶対/相対パスの場合: そのまま使用（後方互換性）
|
||||||
|
- `$ARGUMENTS` がない場合:
|
||||||
|
- `.ai-agent/sessions/` ディレクトリから `*-[0-9]*.md` パターンで検索
|
||||||
|
- 最も新しく更新されたファイルを使用
|
||||||
|
- 複数見つかった場合: 最新のファイルを使用し、他のファイルも一覧表示
|
||||||
|
- `.ai-agent/sessions/` が存在しない、またはファイルが見つからない場合: カレントディレクトリにフォールバック（後方互換性）
|
||||||
|
- それでも見つからない場合: エラーメッセージを表示し、`/save-context` の使用を提案
|
||||||
|
|
||||||
|
2. **ファイルの内容を読み込み**:
|
||||||
|
- 指定されたファイルを読み込む
|
||||||
|
- ファイルが存在しない場合は、わかりやすいエラーメッセージを表示
|
||||||
|
|
||||||
|
3. **内容を要約して表示**:
|
||||||
|
- **作業の目的・背景**: なぜこの作業を始めたのか
|
||||||
|
- **現在の進捗状況**: 前回どこまで進んでいたか
|
||||||
|
- **完了済み項目**: これまでに完了した作業
|
||||||
|
- **未完了項目と優先度**: 残りの作業と優先順位
|
||||||
|
- **発見事項・課題**: 実装中に判明した問題点
|
||||||
|
- **技術的決定事項**: 採用した技術やアプローチ
|
||||||
|
- **次に取り組むべきタスク**: 作業を再開する際の推奨アクション
|
||||||
|
|
||||||
|
4. **作業継続のための推奨アクションを提案**:
|
||||||
|
- 次のステップの具体的な提案
|
||||||
|
- 必要なファイルやリソースの確認
|
||||||
|
- 関連する実装計画ファイル（`*-plan.md`）があれば提案
|
||||||
|
|
||||||
|
## 引数
|
||||||
|
|
||||||
|
`$ARGUMENTS` (オプション) - ファイル名（`@` 記法にも対応、例: `current-work.md` または `@current-work.md`）
|
||||||
|
|
||||||
|
指定がない場合は、`.ai-agent/sessions/` ディレクトリから `*-[0-9]*.md` パターンで検索し、最も新しいコンテキストファイルを自動選択します。
|
||||||
|
|
||||||
|
## 使用例
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# ファイル名を指定して読み込み（.ai-agent/sessions/ 内を検索）
|
||||||
|
/load-context authentication-feature-202510301730.md
|
||||||
|
# → .ai-agent/sessions/authentication-feature-202510301730.md を読み込み
|
||||||
|
|
||||||
|
# @記法で指定
|
||||||
|
/load-context @authentication-feature-202510301730.md
|
||||||
|
|
||||||
|
# ファイル名を省略（自動検索: .ai-agent/sessions/ 内の最新ファイル）
|
||||||
|
/load-context
|
||||||
|
```
|
||||||
|
|
||||||
|
## 出力例
|
||||||
|
|
||||||
|
```
|
||||||
|
# 作業コンテキスト: ユーザー認証機能の実装
|
||||||
|
|
||||||
|
前回の保存: 2025-10-30 15:30:00
|
||||||
|
|
||||||
|
## 作業の目的
|
||||||
|
EC-CUBEプラグインにOAuth2.0ベースのユーザー認証機能を追加
|
||||||
|
|
||||||
|
## 前回の進捗状況
|
||||||
|
- 認証APIエンドポイントの実装完了
|
||||||
|
- トークン管理機能の実装完了
|
||||||
|
- テストコードは未着手
|
||||||
|
|
||||||
|
## 発見事項
|
||||||
|
- トークンの有効期限は環境変数で設定可能にした
|
||||||
|
- リフレッシュトークンのローテーション機能を追加した
|
||||||
|
|
||||||
|
## 次のアクション
|
||||||
|
1. 認証機能のユニットテストを作成
|
||||||
|
2. 統合テストでエンドツーエンドの動作確認
|
||||||
|
3. エラーハンドリングの改善
|
||||||
|
|
||||||
|
関連する実装計画ファイル: authentication-feature-plan.md
|
||||||
|
```
|
||||||
|
|
||||||
|
## 実際のユースケース
|
||||||
|
|
||||||
|
前セッションで `/save-context` により保存されたコンテキストを新セッションで復元し、作業を継続します。
|
||||||
|
|
||||||
|
```
|
||||||
|
1. 前セッションで `/save-context`
|
||||||
|
→ 自動生成: `.ai-agent/sessions/authentication-feature-202510301730.md`
|
||||||
|
2. `/clear` でコンテキストクリア
|
||||||
|
3. 新セッションで `/load-context` ← ここで使用（自動的に最新ファイルを読み込み）
|
||||||
|
4. 作業継続
|
||||||
|
|
||||||
|
または、明示的にファイル名を指定:
|
||||||
|
1. `/save-context my-work.md`
|
||||||
|
→ `.ai-agent/sessions/my-work.md` に保存
|
||||||
|
2. `/clear`
|
||||||
|
3. `/load-context my-work.md`
|
||||||
|
→ `.ai-agent/sessions/my-work.md` から読み込み
|
||||||
|
```
|
||||||
|
|
||||||
|
## 注意事項
|
||||||
|
|
||||||
|
- ファイルが見つからない場合は、`/save-context` の使用を提案します
|
||||||
|
- 複数の関連ファイル（実装計画など）がある場合は、それらの読み込みも提案します
|
||||||
|
- 古いコンテキストファイルの場合は、更新日時を表示して注意を促します
|
||||||
82
commands/load-plan.md
Normal file
82
commands/load-plan.md
Normal file
@@ -0,0 +1,82 @@
|
|||||||
|
# 実装計画の読み込み
|
||||||
|
|
||||||
|
このコマンドは、保存された実装計画を読み込んで、進捗状況を把握します。
|
||||||
|
コンテキストクリア後の新セッションで実装作業を継続する際に使用します。
|
||||||
|
|
||||||
|
## 手順
|
||||||
|
|
||||||
|
1. **ファイルの特定**:
|
||||||
|
- `$ARGUMENTS` が指定されている場合:
|
||||||
|
- `@` 記法に対応（例: `@feature-plan.md` → `feature-plan.md`）
|
||||||
|
- ファイル名のみの場合: `.ai-agent/plans/<ファイル名>` を検索
|
||||||
|
- 絶対/相対パスの場合: そのまま使用（後方互換性）
|
||||||
|
- `$ARGUMENTS` がない場合:
|
||||||
|
- `.ai-agent/plans/` ディレクトリから `*-plan.md` パターンで検索
|
||||||
|
- 最も新しく更新されたファイルを使用
|
||||||
|
- 複数見つかった場合: 最新のファイルを使用し、他のファイルも一覧表示
|
||||||
|
- `.ai-agent/plans/` が存在しない、またはファイルが見つからない場合: カレントディレクトリにフォールバック（後方互換性）
|
||||||
|
- それでも見つからない場合: エラーメッセージを表示し、`/create-plan` の使用を提案
|
||||||
|
|
||||||
|
2. **ファイルの内容を読み込み**:
|
||||||
|
- 指定されたファイルを読み込む
|
||||||
|
- チェックリスト項目を抽出・解析
|
||||||
|
|
||||||
|
3. **進捗状況を要約**:
|
||||||
|
- **実装の目的・概要**: ファイルから実装の全体像を把握
|
||||||
|
- **総タスク数と完了数**: `- [ ]` と `- [x]` の数をカウント
|
||||||
|
- **完了済み項目のリスト**: `- [x]` でマークされた項目
|
||||||
|
- **未完了項目のリスト**: `- [ ]` の項目を優先度順に表示
|
||||||
|
- **進捗率**: `(完了数 / 総数) × 100%`
|
||||||
|
|
||||||
|
4. **作業再開のための推奨アクションを提案**:
|
||||||
|
- 次に取り組むべきタスク（最初の未完了項目）
|
||||||
|
- 依存関係がある場合はその情報
|
||||||
|
- 実装に必要なファイルやリソース
|
||||||
|
|
||||||
|
## 引数
|
||||||
|
|
||||||
|
`$ARGUMENTS` (オプション) - ファイル名（`@` 記法にも対応、例: `feature-plan.md` または `@feature-plan.md`）
|
||||||
|
|
||||||
|
## 使用例
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# ファイル名を指定して読み込み（.ai-agent/plans/ 内を検索）
|
||||||
|
/load-plan authentication-feature-plan.md
|
||||||
|
# → .ai-agent/plans/authentication-feature-plan.md を読み込み
|
||||||
|
|
||||||
|
# @記法で指定
|
||||||
|
/load-plan @authentication-feature-plan.md
|
||||||
|
|
||||||
|
# ファイル名を省略（自動検索: .ai-agent/plans/ 内の最新ファイル）
|
||||||
|
/load-plan
|
||||||
|
```
|
||||||
|
|
||||||
|
## 出力例
|
||||||
|
|
||||||
|
```
|
||||||
|
# 実装計画: ユーザー認証機能
|
||||||
|
|
||||||
|
## 進捗状況
|
||||||
|
- 総タスク数: 5
|
||||||
|
- 完了: 2 (40%)
|
||||||
|
- 未完了: 3 (60%)
|
||||||
|
|
||||||
|
## 完了済み
|
||||||
|
- [x] ユーザー認証APIの実装
|
||||||
|
- [x] トークン管理機能の追加
|
||||||
|
|
||||||
|
## 未完了（優先度順）
|
||||||
|
- [ ] テストコードの作成
|
||||||
|
- [ ] ドキュメントの更新
|
||||||
|
- [ ] エラーハンドリングの改善
|
||||||
|
|
||||||
|
## 次のアクション
|
||||||
|
次は「テストコードの作成」に取り組むことをお勧めします。
|
||||||
|
認証APIとトークン管理が完成しているため、これらの機能のテストから始めましょう。
|
||||||
|
```
|
||||||
|
|
||||||
|
## 注意事項
|
||||||
|
|
||||||
|
- ファイルが見つからない場合は、わかりやすいエラーメッセージを表示します
|
||||||
|
- チェックリスト以外の内容（概要、備考など）も読み込んで表示します
|
||||||
|
- 複数のファイルが見つかった場合は、選択を促します
|
||||||
98
commands/save-context.md
Normal file
98
commands/save-context.md
Normal file
@@ -0,0 +1,98 @@
|
|||||||
|
# 会話コンテキストの保存
|
||||||
|
|
||||||
|
このコマンドは、現在の会話内容と作業状況を指定ファイルにMarkdown形式で保存します。
|
||||||
|
コンテキストが限界に達した際に、`/clear` 前に使用することで作業の継続性を保ちます。
|
||||||
|
|
||||||
|
## 手順
|
||||||
|
|
||||||
|
1. **ファイル名の決定**:
|
||||||
|
- `$ARGUMENTS` が指定されている場合: そのファイル名を使用
|
||||||
|
- `$ARGUMENTS` がない場合:
|
||||||
|
a. 現在の会話内容から作業内容を分析し、簡潔な英語のキーワード（2-4単語）を抽出
|
||||||
|
例: "authentication-feature", "bug-fix-order", "refactor-payment"
|
||||||
|
b. 現在時刻のタイムスタンプ（YYYYMMDDhhmm形式）を生成
|
||||||
|
c. ファイル名を `<キーワード>-<YYYYMMDDhhmm>.md` の形式で生成
|
||||||
|
例: `authentication-feature-202510301730.md`
|
||||||
|
|
||||||
|
2. **最近の会話から以下を抽出**:
|
||||||
|
- **作業の目的・背景**: なぜこの作業を始めたのか
|
||||||
|
- **現在の進捗状況**: どこまで進んでいるか
|
||||||
|
- **発見事項・課題**: 実装中に判明した問題点や注意事項
|
||||||
|
- **技術的な決定事項**: 採用した技術やアプローチ
|
||||||
|
- **次のアクション**: これから何をする必要があるか
|
||||||
|
|
||||||
|
3. **Markdown形式で整形**:
|
||||||
|
```markdown
|
||||||
|
# 作業コンテキスト
|
||||||
|
|
||||||
|
保存日時: YYYY-MM-DD HH:MM:SS
|
||||||
|
|
||||||
|
## 作業概要
|
||||||
|
[作業の目的と背景]
|
||||||
|
|
||||||
|
## 現在の状況
|
||||||
|
[進捗状況と完了した内容]
|
||||||
|
|
||||||
|
## 発見事項
|
||||||
|
[実装中に判明した問題点や注意事項]
|
||||||
|
|
||||||
|
## 技術的決定事項
|
||||||
|
[採用した技術やアプローチ]
|
||||||
|
|
||||||
|
## 残りのタスク
|
||||||
|
[未完了の作業と次に取り組むべきこと]
|
||||||
|
|
||||||
|
## 参考情報
|
||||||
|
[関連ファイル、URL、その他の参考情報]
|
||||||
|
```
|
||||||
|
|
||||||
|
4. **ファイルに書き込み**:
|
||||||
|
- `.ai-agent/sessions/` ディレクトリが存在しない場合は作成（`mkdir -p .ai-agent/sessions`）
|
||||||
|
- 指定されたファイル名で `.ai-agent/sessions/` 以下に保存
|
||||||
|
- 保存先: `.ai-agent/sessions/<ファイル名>`
|
||||||
|
|
||||||
|
5. **保存完了を報告**:
|
||||||
|
- 保存したファイル名
|
||||||
|
- 保存した内容の概要
|
||||||
|
- 次のステップ（`/clear` の使用を提案）
|
||||||
|
|
||||||
|
## 引数
|
||||||
|
|
||||||
|
`$ARGUMENTS` (オプション) - 保存先ファイル名（例: `current-work.md`）
|
||||||
|
|
||||||
|
指定がない場合は、会話内容から作業を推測し、`<作業内容>-<YYYYMMDDhhmm>.md` 形式で自動生成されます。
|
||||||
|
例: `authentication-feature-202510301730.md`
|
||||||
|
|
||||||
|
## 使用例
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# ファイル名を指定して保存
|
||||||
|
/save-context current-work.md
|
||||||
|
# → .ai-agent/sessions/current-work.md に保存
|
||||||
|
|
||||||
|
# ファイル名を省略（自動生成: 作業内容-タイムスタンプ.md）
|
||||||
|
/save-context
|
||||||
|
# 例: .ai-agent/sessions/authentication-feature-202510301730.md が生成される
|
||||||
|
```
|
||||||
|
|
||||||
|
## 実際のユースケース
|
||||||
|
|
||||||
|
```
|
||||||
|
1. コンテキストが残り少ない → `/save-context`
|
||||||
|
→ 自動生成: `.ai-agent/sessions/authentication-feature-202510301730.md`
|
||||||
|
2. `/clear` でコンテキストクリア
|
||||||
|
3. 新セッションで `/load-context authentication-feature-202510301730.md` で状況把握
|
||||||
|
4. 作業継続
|
||||||
|
|
||||||
|
または、明示的にファイル名を指定:
|
||||||
|
1. `/save-context my-important-work.md`
|
||||||
|
→ `.ai-agent/sessions/my-important-work.md` に保存
|
||||||
|
2. `/clear`
|
||||||
|
3. `/load-context my-important-work.md`
|
||||||
|
```
|
||||||
|
|
||||||
|
## 注意事項
|
||||||
|
|
||||||
|
- 既存のファイルが存在する場合は上書きされます
|
||||||
|
- 機密情報（パスワード、APIキーなど）は保存しないよう注意してください
|
||||||
|
- コンテキストファイルは定期的に整理することを推奨します
|
||||||
77
commands/update-plan.md
Normal file
77
commands/update-plan.md
Normal file
@@ -0,0 +1,77 @@
|
|||||||
|
# 実装計画の更新
|
||||||
|
|
||||||
|
このコマンドは、既存の実装計画ファイルを読み込み、進捗に合わせて更新します。
|
||||||
|
|
||||||
|
## 手順
|
||||||
|
|
||||||
|
1. **ファイルの特定**:
|
||||||
|
- `$ARGUMENTS` が指定されている場合:
|
||||||
|
- ファイル名のみの場合: `.ai-agent/plans/<ファイル名>` を検索
|
||||||
|
- 絶対/相対パスの場合: そのまま使用（後方互換性）
|
||||||
|
- `$ARGUMENTS` がない場合:
|
||||||
|
- `.ai-agent/plans/` ディレクトリから `*-plan.md` パターンで検索
|
||||||
|
- 最も新しく更新されたファイルを使用
|
||||||
|
- 複数見つかった場合: 最新のファイルを使用し、他のファイルも一覧表示
|
||||||
|
- `.ai-agent/plans/` が存在しない、またはファイルが見つからない場合: カレントディレクトリにフォールバック（後方互換性）
|
||||||
|
- それでも見つからない場合: エラーメッセージを表示し、`/create-plan` の使用を提案
|
||||||
|
|
||||||
|
2. **既存のチェックリストを読み込み**:
|
||||||
|
- ファイルの内容を読み込む
|
||||||
|
- 現在のチェックリスト項目を抽出
|
||||||
|
|
||||||
|
3. **会話内容から進捗を判断**:
|
||||||
|
- 最近の会話から完了した作業を特定
|
||||||
|
- 完了した項目に `[x]` チェックマークを付ける
|
||||||
|
- 新しく発見した作業項目を追加
|
||||||
|
- 不要になった項目を削除または ~~取り消し線~~ で注釈
|
||||||
|
|
||||||
|
4. **更新したチェックリストをファイルに書き込み**:
|
||||||
|
- 元のファイル構造を保持しながら更新
|
||||||
|
- タイムスタンプや更新履歴を追記（オプション）
|
||||||
|
|
||||||
|
5. **更新内容を報告**:
|
||||||
|
- 完了した項目数 / 総項目数
|
||||||
|
- 新規追加された項目
|
||||||
|
- 削除または変更された項目
|
||||||
|
- 次に取り組むべき未完了項目
|
||||||
|
|
||||||
|
## 引数
|
||||||
|
|
||||||
|
`$ARGUMENTS` (オプション) - ファイル名（例: `authentication-feature-plan.md`）
|
||||||
|
|
||||||
|
## 使用例
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# ファイル名を指定して更新（.ai-agent/plans/ 内を検索）
|
||||||
|
/update-plan authentication-feature-plan.md
|
||||||
|
# → .ai-agent/plans/authentication-feature-plan.md を更新
|
||||||
|
|
||||||
|
# ファイル名を省略（自動検索: .ai-agent/plans/ 内の最新ファイル）
|
||||||
|
/update-plan
|
||||||
|
```
|
||||||
|
|
||||||
|
## 更新の例
|
||||||
|
|
||||||
|
### 更新前:
|
||||||
|
```markdown
|
||||||
|
## 実装計画
|
||||||
|
|
||||||
|
- [ ] ユーザー認証APIの実装
|
||||||
|
- [ ] トークン管理機能の追加
|
||||||
|
- [ ] テストコードの作成
|
||||||
|
```
|
||||||
|
|
||||||
|
### 更新後:
|
||||||
|
```markdown
|
||||||
|
## 実装計画
|
||||||
|
|
||||||
|
- [x] ユーザー認証APIの実装
|
||||||
|
- [x] トークン管理機能の追加
|
||||||
|
- [ ] テストコードの作成
|
||||||
|
- [ ] ドキュメントの更新（新規追加）
|
||||||
|
```
|
||||||
|
|
||||||
|
## 注意事項
|
||||||
|
|
||||||
|
- 会話内容から完了判定できない場合は、現状維持します
|
||||||
|
- 手動で編集した内容は可能な限り保持します
|
||||||
48
commands/update-pr-description.md
Normal file
48
commands/update-pr-description.md
Normal file
@@ -0,0 +1,48 @@
|
|||||||
|
# PR/Issue 説明更新コマンド
|
||||||
|
|
||||||
|
このコマンドは、git push 後に指定された番号のPRまたはIssueの説明を最新のコミット内容に基づいて更新します。
|
||||||
|
|
||||||
|
## 手順
|
||||||
|
|
||||||
|
1. 引数から PR/Issue 番号を抽出（#123, PR #123, Issue #123 などの形式に対応）
|
||||||
|
2. 現在のブランチの最新コミット履歴を確認
|
||||||
|
3. PR または Issue の現在の説明を取得
|
||||||
|
4. `pr-<no>.md` または `issue-<no>.md` というファイル名で docs 以下に現在の説明を保存
|
||||||
|
5. 新しいコミット内容を分析して説明のファイルを更新
|
||||||
|
6. 更新された説明のファイルでPR/Issueを編集
|
||||||
|
|
||||||
|
## 引数
|
||||||
|
|
||||||
|
$ARGUMENTS - PR/Issue番号（必須）
|
||||||
|
- 例: "#123", "PR #123", "Issue #123", "123"
|
||||||
|
|
||||||
|
## 実装詳細
|
||||||
|
|
||||||
|
1. `git branch --show-current` で現在のブランチを確認
|
||||||
|
2. `git log --oneline -10` で最新10件のコミットを取得
|
||||||
|
3. 番号からタイプを判定：
|
||||||
|
- まず `gh pr view <番号>` を試行してPRかチェック
|
||||||
|
- 失敗した場合は `gh issue view <番号>` を試行してIssueかチェック
|
||||||
|
4. PRの場合：
|
||||||
|
- `gh pr view <番号> --json title,body` で現在のタイトルと説明を取得
|
||||||
|
- `git log main..HEAD --oneline` でPR対象のコミット一覧を取得
|
||||||
|
- コミット内容を分析して説明を生成・更新
|
||||||
|
- `gh pr edit <番号> --body "更新された説明"` で説明を更新
|
||||||
|
5. Issueの場合：
|
||||||
|
- `gh issue view <番号> --json title,body` で現在のタイトルと説明を取得
|
||||||
|
- 関連するコミットの変更内容を分析
|
||||||
|
- `gh issue edit <番号> --body "更新された説明"` で説明を更新
|
||||||
|
|
||||||
|
## 説明生成ルール
|
||||||
|
|
||||||
|
- 元の説明を保持しつつ、「## 最新の変更」セクションを追加または更新
|
||||||
|
- コミットメッセージから主要な変更点を抽出
|
||||||
|
- 変更されたファイルの種類に応じて適切なカテゴリで整理
|
||||||
|
- Conventional Commit形式のコミットメッセージを理解して要約
|
||||||
|
|
||||||
|
## エラーハンドリング
|
||||||
|
|
||||||
|
- PR/Issue番号が指定されていない場合は、入力を求める
|
||||||
|
- 指定された番号のPR/Issueが見つからない場合は、エラーメッセージを表示
|
||||||
|
- コミット履歴が取得できない場合は、現在のブランチ状態を確認するよう促す
|
||||||
|
- GitHub CLIの認証エラーの場合は、`gh auth login` を案内
|
||||||
26
hooks/hooks.json
Normal file
26
hooks/hooks.json
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
{
|
||||||
|
"hooks": {
|
||||||
|
"Notification": [
|
||||||
|
{
|
||||||
|
"matcher": "",
|
||||||
|
"hooks": [
|
||||||
|
{
|
||||||
|
"type": "command",
|
||||||
|
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/slack-notify.sh notification"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"Stop": [
|
||||||
|
{
|
||||||
|
"matcher": "",
|
||||||
|
"hooks": [
|
||||||
|
{
|
||||||
|
"type": "command",
|
||||||
|
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/slack-notify.sh stop"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
}
|
||||||
335
hooks/slack-notify.sh
Executable file
335
hooks/slack-notify.sh
Executable file
@@ -0,0 +1,335 @@
|
|||||||
|
#!/bin/bash
|
||||||
|
#
|
||||||
|
# Slack Notification Script for Claude Code Hooks
|
||||||
|
# =================================================
|
||||||
|
# This script extracts user prompts and assistant responses from conversation
|
||||||
|
# history, generates a summary using Gemini AI, and sends it to Slack.
|
||||||
|
#
|
||||||
|
# Usage:
|
||||||
|
# echo '{"transcript_path": "/path/to/file.jsonl", "title": "Task"}' | ./slack-notify.sh [notification|stop]
|
||||||
|
#
|
||||||
|
# Environment Variables:
|
||||||
|
# ECCUBE_DEV_AGENTS_SLACK_WEBHOOK_URL - Slack webhook URL (required)
|
||||||
|
# DEBUG - Set to 1 to enable debug output
|
||||||
|
#
|
||||||
|
|
||||||
|
set -euo pipefail
|
||||||
|
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
# Configuration
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
readonly SCRIPT_NAME="$(basename "$0")"
|
||||||
|
readonly MESSAGE_LIMIT=10 # Number of recent messages to extract
|
||||||
|
readonly DEBUG="${DEBUG:-0}"
|
||||||
|
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
# Utility Functions
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
# Print error message to stderr
|
||||||
|
error() {
|
||||||
|
echo "ERROR: $*" >&2
|
||||||
|
}
|
||||||
|
|
||||||
|
# Print debug message if DEBUG is enabled
|
||||||
|
debug() {
|
||||||
|
if [[ "$DEBUG" == "1" ]]; then
|
||||||
|
echo "DEBUG: $*" >&2
|
||||||
|
fi
|
||||||
|
}
|
||||||
|
|
||||||
|
# Print info message to stderr
|
||||||
|
info() {
|
||||||
|
echo "INFO: $*" >&2
|
||||||
|
}
|
||||||
|
|
||||||
|
# Exit with error message
|
||||||
|
die() {
|
||||||
|
error "$@"
|
||||||
|
exit 1
|
||||||
|
}
|
||||||
|
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
# Input Processing
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
# Read and parse JSON input from stdin
|
||||||
|
read_input() {
|
||||||
|
local input
|
||||||
|
input=$(cat)
|
||||||
|
debug "Received input: ${input:0:100}..."
|
||||||
|
echo "$input"
|
||||||
|
}
|
||||||
|
|
||||||
|
# Extract transcript path from input JSON
|
||||||
|
extract_transcript_path() {
|
||||||
|
local input="$1"
|
||||||
|
local path
|
||||||
|
|
||||||
|
path=$(echo "$input" | jq -r '.transcript_path')
|
||||||
|
|
||||||
|
if [[ "$path" == "null" || -z "$path" ]]; then
|
||||||
|
die "transcript_path not found in input JSON"
|
||||||
|
fi
|
||||||
|
|
||||||
|
if [[ ! -f "$path" ]]; then
|
||||||
|
die "Transcript file not found: $path"
|
||||||
|
fi
|
||||||
|
|
||||||
|
debug "Transcript path: $path"
|
||||||
|
echo "$path"
|
||||||
|
}
|
||||||
|
|
||||||
|
# Extract title from input JSON
|
||||||
|
extract_title() {
|
||||||
|
local input="$1"
|
||||||
|
local title
|
||||||
|
|
||||||
|
title=$(echo "$input" | jq -r '.title // "Untitled"')
|
||||||
|
debug "Title: $title"
|
||||||
|
echo "$title"
|
||||||
|
}
|
||||||
|
|
||||||
|
# Determine event type (notification or stop)
|
||||||
|
determine_event_type() {
|
||||||
|
local event_type="${1:-notification}"
|
||||||
|
|
||||||
|
if [[ "$event_type" != "notification" && "$event_type" != "stop" ]]; then
|
||||||
|
error "Unknown event type: $event_type, defaulting to notification"
|
||||||
|
event_type="notification"
|
||||||
|
fi
|
||||||
|
|
||||||
|
debug "Event type: $event_type"
|
||||||
|
echo "$event_type"
|
||||||
|
}
|
||||||
|
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
# Message Extraction
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
# Extract recent messages from transcript file
|
||||||
|
extract_messages() {
|
||||||
|
local transcript_path="$1"
|
||||||
|
local messages
|
||||||
|
|
||||||
|
messages=$(jq -s ".[-${MESSAGE_LIMIT}:]" "$transcript_path")
|
||||||
|
debug "Extracted ${MESSAGE_LIMIT} recent messages"
|
||||||
|
echo "$messages"
|
||||||
|
}
|
||||||
|
|
||||||
|
# Extract user prompts from messages
|
||||||
|
extract_user_prompts() {
|
||||||
|
local messages="$1"
|
||||||
|
local prompts
|
||||||
|
|
||||||
|
prompts=$(echo "$messages" | jq -r '
|
||||||
|
[.[] |
|
||||||
|
select(.type == "user" and .message.content[0].text != null) |
|
||||||
|
.message.content[0].text
|
||||||
|
] | join("\n---\n")
|
||||||
|
')
|
||||||
|
|
||||||
|
debug "Extracted user prompts (length: ${#prompts})"
|
||||||
|
echo "$prompts"
|
||||||
|
}
|
||||||
|
|
||||||
|
# Extract assistant responses from messages
|
||||||
|
extract_assistant_responses() {
|
||||||
|
local messages="$1"
|
||||||
|
local responses
|
||||||
|
|
||||||
|
responses=$(echo "$messages" | jq -r '
|
||||||
|
[.[] |
|
||||||
|
select(.type == "assistant" and .message.content[0].text != null) |
|
||||||
|
.message.content[0].text
|
||||||
|
] | join("\n---\n")
|
||||||
|
')
|
||||||
|
|
||||||
|
debug "Extracted assistant responses (length: ${#responses})"
|
||||||
|
echo "$responses"
|
||||||
|
}
|
||||||
|
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
# Summary Generation
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
# Build Gemini prompt based on event type
|
||||||
|
build_gemini_prompt() {
|
||||||
|
local event_type="$1"
|
||||||
|
local title="$2"
|
||||||
|
local user_prompts="$3"
|
||||||
|
local assistant_responses="$4"
|
||||||
|
local prompt
|
||||||
|
|
||||||
|
local context="タイトル: $title
|
||||||
|
|
||||||
|
【ユーザーの入力】
|
||||||
|
$user_prompts
|
||||||
|
|
||||||
|
【Claudeの応答】
|
||||||
|
$assistant_responses"
|
||||||
|
|
||||||
|
if [[ "$event_type" == "stop" ]]; then
|
||||||
|
prompt="タスク完了の通知です。以下の会話を要約してください：
|
||||||
|
|
||||||
|
$context
|
||||||
|
|
||||||
|
以下の形式で日本語で要約してください：
|
||||||
|
|
||||||
|
📝 *ユーザーの依頼:*
|
||||||
|
[ユーザーが入力したプロンプト/質問の要点を簡潔に]
|
||||||
|
|
||||||
|
🤖 *対応内容:*
|
||||||
|
[Claude Codeが実施した作業の概要]
|
||||||
|
|
||||||
|
✅ *結果:*
|
||||||
|
[完了したタスクの成果]
|
||||||
|
|
||||||
|
絵文字を使って読みやすくし、Slack の mrkdwn 形式を使用してください。"
|
||||||
|
else
|
||||||
|
prompt="タスク確認の通知です。以下の会話を要約してください：
|
||||||
|
|
||||||
|
$context
|
||||||
|
|
||||||
|
以下の形式で日本語で要約してください：
|
||||||
|
|
||||||
|
📝 *ユーザーの依頼:*
|
||||||
|
[ユーザーが入力したプロンプト/質問の要点を簡潔に]
|
||||||
|
|
||||||
|
🤖 *対応内容:*
|
||||||
|
[Claude Codeが実施した作業の概要]
|
||||||
|
|
||||||
|
絵文字を使って読みやすくし、Slack の mrkdwn 形式を使用してください。"
|
||||||
|
fi
|
||||||
|
|
||||||
|
debug "Built Gemini prompt (length: ${#prompt})"
|
||||||
|
echo "$prompt"
|
||||||
|
}
|
||||||
|
|
||||||
|
# Generate summary using Gemini AI
|
||||||
|
generate_summary() {
|
||||||
|
local prompt="$1"
|
||||||
|
local summary
|
||||||
|
|
||||||
|
info "Generating summary with Gemini AI..."
|
||||||
|
|
||||||
|
if ! summary=$(echo "$prompt" | gemini -m gemini-2.5-flash 2>&1); then
|
||||||
|
die "Failed to generate summary with Gemini: $summary"
|
||||||
|
fi
|
||||||
|
|
||||||
|
debug "Summary generated (length: ${#summary})"
|
||||||
|
echo "$summary"
|
||||||
|
}
|
||||||
|
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
# Slack Integration
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
# Check if Slack webhook URL is configured
|
||||||
|
check_slack_webhook() {
|
||||||
|
if [[ -z "${ECCUBE_DEV_AGENTS_SLACK_WEBHOOK_URL:-}" ]]; then
|
||||||
|
error "ECCUBE_DEV_AGENTS_SLACK_WEBHOOK_URL is not set"
|
||||||
|
info "Skipping Slack notification"
|
||||||
|
return 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
debug "Slack webhook URL is configured"
|
||||||
|
return 0
|
||||||
|
}
|
||||||
|
|
||||||
|
# Build Slack message payload
|
||||||
|
build_slack_payload() {
|
||||||
|
local summary="$1"
|
||||||
|
local payload
|
||||||
|
|
||||||
|
payload=$(jq -n --arg text "$summary" '{
|
||||||
|
blocks: [
|
||||||
|
{
|
||||||
|
type: "section",
|
||||||
|
text: {
|
||||||
|
type: "mrkdwn",
|
||||||
|
text: $text
|
||||||
|
}
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}')
|
||||||
|
|
||||||
|
debug "Built Slack payload"
|
||||||
|
echo "$payload"
|
||||||
|
}
|
||||||
|
|
||||||
|
# Send notification to Slack
|
||||||
|
send_to_slack() {
|
||||||
|
local payload="$1"
|
||||||
|
local response
|
||||||
|
|
||||||
|
info "Sending notification to Slack..."
|
||||||
|
|
||||||
|
if ! response=$(curl -s -w "\n%{http_code}" -X POST \
|
||||||
|
-H 'Content-type: application/json' \
|
||||||
|
-d "$payload" \
|
||||||
|
"${ECCUBE_DEV_AGENTS_SLACK_WEBHOOK_URL}" 2>&1); then
|
||||||
|
die "Failed to send to Slack: $response"
|
||||||
|
fi
|
||||||
|
|
||||||
|
local http_code
|
||||||
|
http_code=$(echo "$response" | tail -n1)
|
||||||
|
|
||||||
|
if [[ "$http_code" != "200" ]]; then
|
||||||
|
die "Slack API returned error code: $http_code"
|
||||||
|
fi
|
||||||
|
|
||||||
|
info "Slack notification sent successfully"
|
||||||
|
}
|
||||||
|
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
# Main Function
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
main() {
|
||||||
|
local event_type
|
||||||
|
event_type=$(determine_event_type "${1:-}")
|
||||||
|
|
||||||
|
# Read input from stdin
|
||||||
|
local input
|
||||||
|
input=$(read_input)
|
||||||
|
|
||||||
|
# Extract parameters
|
||||||
|
local transcript_path
|
||||||
|
local title
|
||||||
|
transcript_path=$(extract_transcript_path "$input")
|
||||||
|
title=$(extract_title "$input")
|
||||||
|
|
||||||
|
# Extract messages
|
||||||
|
local messages
|
||||||
|
local user_prompts
|
||||||
|
local assistant_responses
|
||||||
|
messages=$(extract_messages "$transcript_path")
|
||||||
|
user_prompts=$(extract_user_prompts "$messages")
|
||||||
|
assistant_responses=$(extract_assistant_responses "$messages")
|
||||||
|
|
||||||
|
# Generate summary
|
||||||
|
local gemini_prompt
|
||||||
|
local summary
|
||||||
|
gemini_prompt=$(build_gemini_prompt "$event_type" "$title" "$user_prompts" "$assistant_responses")
|
||||||
|
summary=$(generate_summary "$gemini_prompt")
|
||||||
|
|
||||||
|
# Send to Slack (if configured)
|
||||||
|
if check_slack_webhook; then
|
||||||
|
local payload
|
||||||
|
payload=$(build_slack_payload "$summary")
|
||||||
|
send_to_slack "$payload"
|
||||||
|
else
|
||||||
|
# Just print summary if Slack is not configured
|
||||||
|
echo "=== Generated Summary ==="
|
||||||
|
echo "$summary"
|
||||||
|
echo "========================="
|
||||||
|
fi
|
||||||
|
}
|
||||||
|
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
# Script Entry Point
|
||||||
|
# -----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
main "$@"
|
||||||
113
plugin.lock.json
Normal file
113
plugin.lock.json
Normal file
@@ -0,0 +1,113 @@
|
|||||||
|
{
|
||||||
|
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||||
|
"pluginId": "gh:nanasess/eccube-dev-agents:plugins/eccube-dev-agents",
|
||||||
|
"normalized": {
|
||||||
|
"repo": null,
|
||||||
|
"ref": "refs/tags/v20251128.0",
|
||||||
|
"commit": "9ed3807eadfb5698d99c88a2b224981227cadd9f",
|
||||||
|
"treeHash": "4c89129dfb28e3e40e5274a039b8e66316d47b462d823a88971c06e1cddc6fa9",
|
||||||
|
"generatedAt": "2025-11-28T10:27:13.686530Z",
|
||||||
|
"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": "eccube-dev-agents",
|
||||||
|
"description": "Comprehensive development toolkit optimized for EC-CUBE/Symfony but applicable to any project. Includes specialized AI agents, Gemini integration, GitHub automation, and Slack notifications",
|
||||||
|
"version": "1.0.0"
|
||||||
|
},
|
||||||
|
"content": {
|
||||||
|
"files": [
|
||||||
|
{
|
||||||
|
"path": "README.md",
|
||||||
|
"sha256": "9a31ba216f1e1c8050e3a10bf6a024340d01c6f1a8828619c2a3330e55d1dabc"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "agents/bug-investigator.md",
|
||||||
|
"sha256": "962a360b3c90b24febc883aae7ac238c1651c393ea971a581f6e6389a3288b6f"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "agents/implementation-analyzer.md",
|
||||||
|
"sha256": "cf24434fda3cf5d06efa28b1b7fe8ed4403f1cb6ce10566e90364c91e4a78353"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "agents/log-analyzer.md",
|
||||||
|
"sha256": "2c409d6d0cea7f8947eec887f3beff195fa4ac9eb36f66119dd1f14400d6cbde"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "agents/refactoring-expert.md",
|
||||||
|
"sha256": "ba52bdd456e82369d5b1d7875d3f89c29f398b13872d01bece165cc313045df3"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "hooks/slack-notify.sh",
|
||||||
|
"sha256": "c2d8d77874b075b7773f3aebb1a9b575b3b76cec8fbda9cb95d40224f938b5a8"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "hooks/hooks.json",
|
||||||
|
"sha256": "c02019b0607556d24d41c38132a3671016e7e01e7bf5ed8e1eb74334d6e03ce1"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": ".claude-plugin/plugin.json",
|
||||||
|
"sha256": "a885d6f8ce207d25b17b7787d567854dfc255b3d8b5dca056410c558a17993a0"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/update-plan.md",
|
||||||
|
"sha256": "2460d37f6120e4ea490d9ed466b6875c1d564c89333f41bcd79eb29729113f67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/github-logs-analyze.md",
|
||||||
|
"sha256": "6cbcb702705678bf656fb534086efd9b3e5a942b94f7f6fc9500f30fe1d97930"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/load-context.md",
|
||||||
|
"sha256": "4f9d320bd3554d8658071f6ae79a64a3a3e7d7158a571851223ffc2441f84a5e"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/save-context.md",
|
||||||
|
"sha256": "c9e47bb8cb54b0989004cddf332bdc7031733f5d02625a948a705ec7beb4ca51"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/gemini-search.md",
|
||||||
|
"sha256": "0fc7487c2f954ebc16682039d93b1ac83fb01cae87da8b14d35d2c6dee6c0787"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/create-pr.md",
|
||||||
|
"sha256": "c2a73f3dcd45b3fe831a231321344f8b7e61ec074a2b40ce7f9d97fe0e7c6f14"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/generate-commit.md",
|
||||||
|
"sha256": "2db24a6cd117ba4ee915bbc5a1c7f62346f8559b27ddc01dc5d302a5bbf57eb5"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/gemini.md",
|
||||||
|
"sha256": "99abdd0dde15b037d3381815366df42150c800d31b88ace4d3abc80a95578f27"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/create-plan.md",
|
||||||
|
"sha256": "48537a192132a82840869800c023615c11f84a0114ab4220a8ca961d7c604a30"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/github-check.md",
|
||||||
|
"sha256": "bf1737f62913cd41f57d919005ae978b776d9b7680db05ea64d4b4a13bd2d61d"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/update-pr-description.md",
|
||||||
|
"sha256": "2b58f0441955a55b27c45c1440309407bdcd6727f7c0c50829e19583821652d9"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/load-plan.md",
|
||||||
|
"sha256": "4d38211cfbab0eecbce671759e35a87fdfc82d0902771b4e852124121a723e13"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"dirSha256": "4c89129dfb28e3e40e5274a039b8e66316d47b462d823a88971c06e1cddc6fa9"
|
||||||
|
},
|
||||||
|
"security": {
|
||||||
|
"scannedAt": null,
|
||||||
|
"scannerVersion": null,
|
||||||
|
"flags": []
|
||||||
|
}
|
||||||
|
}
|
||||||
Reference in New Issue
Block a user