diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index ff4de4f..45487a1 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -8,8 +8,8 @@ { "name": "eccube-dev-agents", "source": "./plugins/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", + "description": "Git workflow automation, GitHub review management, and CI log analysis toolkit for development projects", + "version": "2.0.0", "author": { "name": "nanasess" } diff --git a/CLAUDE.md b/CLAUDE.md index 8c7cf93..9c14414 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -4,153 +4,78 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co ## 概要 -このリポジトリは **eccube-dev-agents** Claude Codeプラグインで、EC-CUBE/Symfony開発に最適化されていますが、汎用的な開発プロジェクトにも適用可能です。 +このリポジトリは **eccube-dev-agents** Claude Codeプラグインです。Git ワークフロー自動化、GitHub レビュー管理、CI ログ分析の Skills を提供します。 ## プラグインアーキテクチャ -### コアコンポーネント +### Skills (`plugins/eccube-dev-agents/skills/`) -1. **Specialized AI Agents** (`agents/`) - - 各エージェントはYAMLフロントマター付きMarkdown形式で定義 - - `name`, `description`, `tools`, `model`, `color`パラメータを含む - - エージェント本体は詳細なプロンプト指示で構成 +各 Skill は `skills//SKILL.md` 形式で定義。YAML フロントマターに `description`, `allowed-tools`, `argument-hint` を含む。 -2. **Custom Commands** (`commands/`) - - スラッシュコマンドとして実行可能なMarkdownファイル - - `$ARGUMENTS`変数を使用した動的パラメータ置換 - - 外部CLIツール（gemini, gh）との統合 - - 12つのコマンド: - - Development workflow: create-plan, update-plan, load-plan, save-context, load-context - - ファイル保存先: `.ai-agent/sessions/` (context), `.ai-agent/plans/` (plans) - - 自動ディレクトリ作成、後方互換性あり（カレントディレクトリへのフォールバック） - - GitHub integration: github-check, github-logs-analyze, generate-commit, update-pr-description, create-pr - - AI search: gemini-search, gemini +提供する Skills: +1. **commit** - Conventional Commits 形式の日本語コミットメッセージ自動生成。複数リポジトリ対応 +2. **commit-push-pr** - コミット + Push + PR作成の一括実行。PRテンプレート自動適用対応 +3. **validate-review** - GitHub レビューコメントの妥当性検証 +4. **reply-review** - GitHub レビューコメントへの一括返信 +5. **github-logs-analyze** - GitHub Actions 失敗ログの解析 +6. **plan** - Issue/PR からチェックリスト形式の実装計画を生成 -3. **Event Hooks** (`hooks/hooks.json`) - - `Notification`と`Stop`イベントに対応 - - Gemini CLI、jq、curlを組み合わせたSlack通知パイプライン - - 会話履歴の最新3メッセージを要約して通知 - -### エージェント設計パターン - -各エージェントは以下の構造に従います： +### Skill 設計パターン ```yaml --- -name: agent-name -description: "When to use this agent..." -tools: [tool1, tool2, ...] -model: sonnet|opus -color: blue|red|green|... +description: Skill の説明（/help に表示） +allowed-tools: Bash(git:*), Bash(gh:*), Read +argument-hint: [引数の説明] --- -# Agent-specific prompt instructions +# Skill のプロンプト本文 ``` -**重要な設計原則**： -- `description`フィールドには使用例を含める（``タグ） -- プロンプトは段階的な調査手順を明示（番号付きリスト） -- EC-CUBE/Symfony固有の知識を含める -- 常に日本語で結果を報告（全エージェント共通） - -### コマンド設計パターン - -スラッシュコマンドは以下のパターンを使用： - -1. **外部ツール統合** (`gemini-search.md`) - - Gemini CLIコマンド: `gemini`（PATHに含まれている必要があります） - - WebSearch機能の活用 - -2. **GitHub CLI統合** (`github-check.md`) - - エージェント連携（`implementation-analyzer`, `log-analyzer`） - - `gh pr view`, `gh issue view`, `gh pr diff`コマンドの使用 - - 番号抽出ロジック（#450, PR #450形式） - -3. **パイプライン処理** (`hooks/hooks.json`) - - `jq`でJSON処理 - - Gemini CLIで要約生成 - - Slack Webhook経由で通知 - ## 開発ワークフロー -### プラグイン開発 - -このプラグイン自体を開発する場合： +### Skill の追加/変更 -1. **エージェント追加/変更** - - `agents/`にMarkdownファイルを作成 - - YAMLフロントマターで設定を定義 - - プロンプトで調査手順を明記 - -2. **コマンド追加/変更** - - `commands/`にMarkdownファイルを作成 - - `$ARGUMENTS`で動的パラメータを受け取る - - 外部ツールのパスは絶対パスで指定 - -3. **フック設定** - - `hooks/hooks.json`でイベントハンドラーを定義 - - 環境変数`ECCUBE_DEV_AGENTS_SLACK_WEBHOOK_URL`が必要 +1. `plugins/eccube-dev-agents/skills//SKILL.md` を作成 +2. YAML フロントマターで `description`, `allowed-tools` を定義 +3. プロンプト本文に手順を記述 ### テストとデバッグ ```bash # プラグイン構造の確認 -ls -la .claude-plugin/ -cat .claude-plugin/plugin.json - -# Git状態の確認 -git status -git log --oneline -5 +ls plugins/eccube-dev-agents/skills/*/SKILL.md +cat plugins/eccube-dev-agents/.claude-plugin/plugin.json -# エージェント/コマンド定義の確認 -cat agents/implementation-analyzer.md -cat commands/github-check.md +# プラグインの再インストール +claude plugin marketplace add /path/to/eccube-dev-agents +claude plugin install eccube-dev-agents ``` ### 配布とインストール -このプラグインは **ネストされた構造** を使用しています： +ネストされた構造を使用: - リポジトリルート: `.claude-plugin/marketplace.json` でマーケットプレイス設定 - プラグイン本体: `plugins/eccube-dev-agents/` サブディレクトリ内 ```bash -# ローカルマーケットプレイス経由でのテスト -# リポジトリルートディレクトリを指定 -claude plugin marketplace add /path/to/eccube-dev-agents +# GitHub経由でインストール +claude plugin marketplace add nanasess/eccube-dev-agents claude plugin install eccube-dev-agents -# GitHub経由での配布 -# リポジトリを公開してGitHub URLでインストール可能 -# claude plugin marketplace add nanasess/eccube-dev-agents -# claude plugin install eccube-dev-agents +# ローカル開発 +claude plugin marketplace add /path/to/eccube-dev-agents +claude plugin install eccube-dev-agents ``` ## 技術的な重要事項 ### 依存関係 -- **Gemini CLI**: `gemini`コマンド（PATHに含まれている必要があります） -- **GitHub CLI**: `gh`コマンド（PR/Issue操作、API呼び出し） -- **jq**: JSON処理（フック内で使用） -- **curl**: Slack Webhook通知 - -### 環境変数 - -- `ECCUBE_DEV_AGENTS_SLACK_WEBHOOK_URL`: Slack通知に必須 +- **GitHub CLI**: `gh` コマンド（PR/Issue操作、API呼び出し、CI ログ取得） ### ファイル形式 -- **エージェント定義**: YAML frontmatter + Markdown本文 -- **コマンド定義**: Markdown形式（変数展開対応） -- **フック定義**: JSON形式 +- **Skill 定義**: YAML frontmatter + Markdown 本文 (`skills//SKILL.md`) - **プラグインメタデータ**: `.claude-plugin/plugin.json` - -## Claude Codeとの統合 - -このプラグインは以下の方法でClaude Codeと統合されます： - -1. **エージェント**: Task toolで`subagent_type`として指定 -2. **コマンド**: `/command-name`形式でスラッシュコマンドとして実行 -3. **フック**: `Notification`と`Stop`イベントで自動実行 - -プラグインが提供する機能は、ユーザーの`~/.config/claude/`設定に自動的に読み込まれます。 +- **マーケットプレイス設定**: `.claude-plugin/marketplace.json` diff --git a/README.md b/README.md index c4abf41..9dbea8a 100644 --- a/README.md +++ b/README.md @@ -1,254 +1,65 @@ -# EC-CUBE Dev Agents +# eccube-dev-agents -**日本語:** EC-CUBE/Symfony開発に特化したAIエージェント、Gemini統合、GitHub自動化、Slack通知を備えた開発ツールキット。EC-CUBE/Symfony向けに最適化されていますが、あらゆる開発プロジェクトに適用可能です。 +Git ワークフロー自動化、GitHub レビュー管理、CI ログ分析の Skills を提供する Claude Code プラグイン。 -**English:** EC-CUBE/Symfony development toolkit with specialized AI agents, Gemini integration, GitHub automation, and Slack notifications. Optimized for EC-CUBE/Symfony but applicable to any development project. +## Skills -## 機能 +| Skill | 説明 | 使い方 | +|-------|------|--------| +| **commit** | Conventional Commits 形式の日本語コミットメッセージ自動生成 | `/commit` | +| **commit-push-pr** | コミット + Push + PR作成（PRテンプレート対応） | `/commit-push-pr` | +| **validate-review** | レビューコメントの妥当性検証 | `/validate-review ` | +| **reply-review** | レビューコメントへの一括返信 | `/reply-review [@user]` | +| **github-logs-analyze** | GitHub Actions 失敗ログの解析 | `/github-logs-analyze ` | +| **plan** | Issue/PR からチェックリスト形式の実装計画を生成 | `/plan [issue-URL]` | -### 🤖 専用AIエージェント +### 特徴 -- **implementation-analyzer** - 仕様書、PR、コミット、ステージング済み変更を調査して実装状況を分析 -- **bug-investigator** - 詳細なエラーログ分析と体系的なデバッグでバグを調査 -- **log-analyzer** - GitHub Actions CI/CDログを分析してテスト失敗の根本原因を特定 -- **refactoring-expert** - コード品質の向上、DRY違反の特定、ベストプラクティスの適用 - -### ⚡ カスタムコマンド - -#### 開発ワークフロー -- **create-plan** - 自動生成されたファイル名でチェックリスト形式の実装計画を作成 -- **update-plan** - 進捗追跡付きで実装計画を更新 -- **load-plan** - 進捗状況と共に実装計画を読み込んで要約 -- **save-context** - 会話コンテキストを、自動生成される説明的なファイル名とタイムスタンプで保存 (例: `auth-feature-202510301730.md`) -- **load-context** - `/clear` 後に作業を再開するために保存したコンテキストを読み込む (最新のコンテキストファイルを自動検出) - -#### GitHub統合 -- **github-check** - 自動番号抽出によるPR/Issue詳細の表示 -- **github-logs-analyze** - 失敗したGitHub Actionsジョブの分析 -- **generate-commit** - git diffからコミットメッセージを生成 -- **update-pr-description** - 変更内容に基づいてPR説明を自動更新 -- **create-pr** - テンプレートサポート、リモート同期チェック、引数解析によるPR作成 - -#### AI検索 -- **gemini-search** - Google Gemini CLIを使用したWeb検索 -- **gemini** - カスタムプロンプトによる直接Gemini CLI操作 - -### 🔔 Slack通知 - -以下の自動通知をSlackに送信: -- タスク完了通知 (Stopフック) -- タスク確認通知 (Notificationフック) -- AIによる会話内容の日本語要約をmrkdwn形式で送信 +- **複数リポジトリ対応**: 親ディレクトリから実行すると変更のあるサブリポジトリを自動検出 +- **PRテンプレート対応**: `.github/pull_request_template.md` を自動検出・適用 +- **ブランチ自動作成**: デフォルトブランチにいる場合に自動でフィーチャーブランチを作成 +- **レビュー管理**: レビューコメントの妥当性検証と一括返信 ## 必要要件 -- **Gemini CLI** - `gemini` コマンドがPATHに含まれている必要があります -- **GitHub CLI (gh)** - GitHub統合コマンド用 -- **jq** - フックコマンド用のJSONプロセッサ -- **curl** - Slack webhook統合用 +- **GitHub CLI (gh)** - GitHub 統合に必須 ## インストール -### クイックスタート (推奨) - -GitHubから直接インストール: - ```bash -# GitHubマーケットプレイスを追加 +# GitHub からインストール claude plugin marketplace add nanasess/eccube-dev-agents - -# プラグインをインストール claude plugin install eccube-dev-agents ``` -**Claude Codeを再起動**してプラグインを有効化してください。 - -### 代替方法: ローカル開発インストール - -プラグイン開発やローカル変更のテスト用: +### ローカル開発 ```bash -# リポジトリをローカルディレクトリにクローン -git clone https://github.com/nanasess/eccube-dev-agents.git /path/to/local/eccube-dev-agents - -# ローカルマーケットプレイスを追加 -# 注意: .claude-plugin/marketplace.json を含むリポジトリルートディレクトリを指定 -claude plugin marketplace add /path/to/local/eccube-dev-agents - -# プラグインをインストール +git clone https://github.com/nanasess/eccube-dev-agents.git +claude plugin marketplace add /path/to/eccube-dev-agents claude plugin install eccube-dev-agents ``` -リポジトリはネストされた構造を使用しており、実際のプラグインコンテンツは `plugins/eccube-dev-agents/` サブディレクトリにあります。ルートにあるmarketplace.jsonがこのレイアウトを設定しています。 - -### 環境設定 - -Slack通知を機能させるには、Slack webhook URLを設定してください: - -```bash -export ECCUBE_DEV_AGENTS_SLACK_WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK/URL" -``` - -これを `~/.bashrc` または `~/.zshrc` に追加すると永続化されます。 - -## 使用方法 - -### エージェントの使用 - -```bash -# 実装状況を分析 -"implementation-analyzer エージェントを使用して現在の実装を分析してください" - -# バグを調査 -"bug-investigator エージェントを使用してこのエラーの根本原因を見つけてください" - -# CIログを分析 -"log-analyzer エージェントを使用してこの失敗したGitHub Actionsの実行を分析してください" - -# コードをリファクタリング -"refactoring-expert エージェントを使用してこのコードをリファクタリングしてください" -``` - -### コマンドの使用 - -#### 開発ワークフローコマンド - -```bash -# 実装計画を作成 (コンテキストからファイル名を自動生成) -/create-plan -# → .ai-agent/plans/ に保存 - -# 特定のファイル名で計画を作成 -/create-plan authentication-feature-plan.md -# → .ai-agent/plans/authentication-feature-plan.md に保存 - -# 実装計画を更新 (.ai-agent/plans/ 内の *-plan.md ファイルを自動検索) -/update-plan - -# 特定の計画を更新 -/update-plan authentication-feature-plan.md - -# 実装計画を読み込む (.ai-agent/plans/ 内を検索) -/load-plan authentication-feature-plan.md - -# クリア前に会話コンテキストを保存 (ファイル名を自動生成) -/save-context -# → 例: .ai-agent/sessions/auth-feature-202510301730.md - -# またはカスタムファイル名を指定 -/save-context my-work.md -# → .ai-agent/sessions/my-work.md に保存 - -# 保存したコンテキストを読み込んで作業を再開 (.ai-agent/sessions/ 内の最新ファイルを自動検出) -/load-context - -# またはファイル名を明示的に指定 -/load-context auth-feature-202510301730.md -``` - -**ファイル構成:** -- コンテキストファイル: `.ai-agent/sessions/` -- 実装計画: `.ai-agent/plans/` -- 両ディレクトリは必要時に自動作成されます - -**典型的なワークフロー:** -```bash -1. /create-plan feature-plan.md # 計画を作成 → .ai-agent/plans/feature-plan.md -2. [実装作業] # コーディング、テストなど -3. /update-plan # 進捗を更新 -4. /save-context # 保存 → .ai-agent/sessions/feature-202511130924.md -5. /clear # コンテキストをクリア -6. /load-context # 復元 (.ai-agent/sessions/ 内の最新を自動検出) -7. /load-plan feature-plan.md # 計画を確認 (.ai-agent/plans/feature-plan.md) -8. [作業を続ける] # 実装を再開 -``` - -#### GitHub統合コマンド - -```bash -# GitHub PRを確認 -/github-check #450 - -# 失敗したCIを分析 -/github-logs-analyze - -# コミットメッセージを生成 -/generate-commit - -# PR説明を更新 -/update-pr-description - -# プルリクエストを作成 -/create-pr - -# オプション付きでPRを作成 -/create-pr --repo upstream/repo --base develop -/create-pr --draft -``` - -#### AI検索コマンド - -```bash -# Web検索 -/gemini-search 最新のEC-CUBE 4.2機能 - -# 直接Gemini操作 -/gemini DoctrineとEloquentの違いを説明してください -``` - -## 設定 - -### フックのカスタマイズ - -`hooks/hooks.json` を編集して通知動作をカスタマイズ: - -- 異なる要約スタイルのためにGeminiプロンプトを変更 -- Slackメッセージ形式を変更 -- 他のイベント用の追加フックを追加 - -### Gemini CLIのセットアップ - -`gemini` コマンドがPATHで利用可能であることを確認してください。カスタムの場所にインストールされている場合: -- PATHに追加: `export PATH="$PATH:/path/to/gemini"` -- またはシンボリックリンクを作成: `ln -s /path/to/gemini/bin/gemini /usr/local/bin/gemini` - ## 構造 ``` eccube-dev-agents/ ├── .claude-plugin/ -│ └── marketplace.json # ローカルマーケットプレイス設定 -├── plugins/eccube-dev-agents/ # プラグインコンテンツ +│ └── marketplace.json +├── plugins/eccube-dev-agents/ │ ├── .claude-plugin/ -│ │ └── plugin.json # プラグインメタデータ -│ ├── agents/ # AIエージェント定義 -│ │ ├── implementation-analyzer.md -│ │ ├── bug-investigator.md -│ │ ├── log-analyzer.md -│ │ └── refactoring-expert.md -│ ├── commands/ # カスタムスラッシュコマンド -│ │ ├── create-plan.md -│ │ ├── update-plan.md -│ │ ├── load-plan.md -│ │ ├── save-context.md -│ │ ├── load-context.md -│ │ ├── gemini-search.md -│ │ ├── gemini.md -│ │ ├── github-check.md -│ │ ├── github-logs-analyze.md -│ │ ├── generate-commit.md -│ │ ├── update-pr-description.md -│ │ └── create-pr.md -│ └── hooks/ -│ └── hooks.json # イベントフック設定 -├── CLAUDE.md # プラグイン開発ガイド +│ │ └── plugin.json +│ └── skills/ +│ ├── commit/SKILL.md +│ ├── commit-push-pr/SKILL.md +│ ├── validate-review/SKILL.md +│ ├── reply-review/SKILL.md +│ ├── github-logs-analyze/SKILL.md +│ └── plan/SKILL.md +├── CLAUDE.md └── README.md ``` -## コントリビューション - -IssueやPull Requestを歓迎します!改善へのご協力をお待ちしています。 - ## ライセンス MIT diff --git a/plugins/eccube-dev-agents/.claude-plugin/plugin.json b/plugins/eccube-dev-agents/.claude-plugin/plugin.json index 29f3516..20d6bf9 100644 --- a/plugins/eccube-dev-agents/.claude-plugin/plugin.json +++ b/plugins/eccube-dev-agents/.claude-plugin/plugin.json @@ -1,19 +1,18 @@ { "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", + "description": "Git workflow automation, GitHub review management, and CI log analysis toolkit for development projects", + "version": "2.0.0", "author": { "name": "nanasess" }, "homepage": "https://github.com/nanasess/eccube-dev-agents", "keywords": [ - "eccube", - "symfony", - "development", - "agents", - "gemini", + "git", "github", - "slack", + "development", + "skills", + "review", + "ci", "automation" ] } diff --git a/plugins/eccube-dev-agents/agents/bug-investigator.md b/plugins/eccube-dev-agents/agents/bug-investigator.md deleted file mode 100644 index c1433c1..0000000 --- a/plugins/eccube-dev-agents/agents/bug-investigator.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -name: bug-investigator -description: バグの調査、エラーログの分析、コードベースの問題解決が必要な場合に使用するエージェントです。使用例： 状況：ユーザーがEC-CUBEアプリケーションでエラーに遭遇し、根本原因の調査を必要としている。 user: "注文処理を実行しようとすると、'Call to undefined method App\Entity\Order::getCustomerName()' というエラーが出ます。原因を調査してもらえますか？" assistant: "bug-investigator エージェントを使用して、このエラーを分析し、現在の実装を調査して根本原因を特定します。" 状況：ユーザーがアプリケーションのエラーログを持っており、何が起きているのか理解したい。 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 エージェントを使用して、これらのエラーログを分析し、データベース接続の問題を調査します。" -model: opus -color: red ---- - -あなたはEC-CUBE、Symfony、PHP、モダンなWebアプリケーションデバッグに深い知識を持つバグ調査の専門家です。あなたの主な役割は、エラーログを体系的に分析し、現在の実装を調査し、バグや問題の根本原因を特定することです。 - -バグを調査する際は、以下を実施してください： - -1. **エラー分析**：提供されたエラーメッセージ、スタックトレース、ログエントリを注意深く解析し、分析します。以下の主要情報を抽出してください： - - エラータイプと重要度 - - 影響を受けるコンポーネントまたはクラス - - 行番号とファイルパス - - トリガーを示す可能性のあるタイムスタンプパターン - - 関連するデータベースクエリや外部サービス呼び出し - -2. **実装調査**：現在のコードベースを体系的に調査して、以下を理解します： - - 影響を受けるメソッド/クラスの実際の実装 - - 関連するコードパスと依存関係 - - 問題を引き起こした可能性のある最近の変更 - - 設定ファイルと環境設定 - - データベーススキーマとエンティティの関係 - -3. **根本原因分析**：体系的なデバッグ手法を適用します： - - エラーに至る実行フローをトレースする - - 欠落しているメソッド、不正な設定、ロジックの欠陥を特定する - - ヌルポインタ例外、型の不一致、依存関係の欠落などの一般的な問題をチェックする - - タイミング問題、競合状態、リソース制約を分析する - - 環境固有の要因（開発環境 vs 本番環境）を考慮する - -4. **コンテキストの理解**：EC-CUBEアーキテクチャの知識を活用します： - - 購入フローバリデータとプロセッサ - - エンティティプロキシシステムと動的拡張 - - プラグインシステムの相互作用 - - クラウドサービス統合（S3、CloudWatch） - - SymfonyフレームワークパターンとDoctrine ORMの動作 - -5. **調査戦略**：構造化されたアプローチに従います： - - 最も明白な潜在的原因から開始する - - ファイル検索とコード調査を使用して仮説を検証する - - 期待される動作について関連するテストファイルを確認する - - 設定ファイルと環境変数をレビューする - - 関連する場合はデータベーススキーマとマイグレーションファイルを調査する - -6. **明確な報告**：以下を含む包括的な調査結果を提供します： - - 問題とその可能性の高い原因の要約 - - 関連する具体的なコードの場所と行番号 - - バグがどのように発生するかの段階的な説明 - - 具体的な実装詳細を含む推奨修正 - - 同様の問題を回避するための予防策 - -常に利用可能なツールを使用して、実際のコードファイルを調査し、関連する実装を検索し、分析を検証してください。徹底的かつ効率的に作業し、最も可能性の高い原因に最初に焦点を当てながらも、初期の仮説が正しくないことが判明した場合はより深く調査する準備をしてください。 - -根本原因を特定したら、必要に応じて具体的なコード変更、設定の更新、アーキテクチャの改善を含む、問題を修正するための実行可能な推奨事項を提供してください。常に日本語で結果を報告してください。 diff --git a/plugins/eccube-dev-agents/agents/implementation-analyzer.md b/plugins/eccube-dev-agents/agents/implementation-analyzer.md deleted file mode 100644 index 78fe763..0000000 --- a/plugins/eccube-dev-agents/agents/implementation-analyzer.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -name: implementation-analyzer -description: 仕様書、PR/Issue説明、ステージング済み変更、最近のコミットを調査して、現在の実装状況を分析し課題を特定するエージェントです。使用例： 状況：ユーザーが新しい決済機能の実装に取り組んでおり、現在の実装状況を把握したい。 user: 'ここ数日、決済機能の実装に取り組んでいます。これまで実装した内容と、まだ必要な作業を分析してもらえますか？' assistant: 'implementation-analyzer エージェントを使用して、最近のコミット、ステージング済み変更、関連する仕様書を調査し、現在の実装状況を評価します。' ユーザーが実装の進捗状況を把握したいため、implementation-analyzer エージェントを使用して最近の作業をレビューし、残りのタスクを特定します。 状況：ユーザーが複雑なPRをレビューしており、実装が要件と一致しているか確認したい。 user: 'PR #450 をレビューして、実装が元の要件と一致しているか確認してください' assistant: 'implementation-analyzer エージェントを使用して PR #450 を調査し、要件と比較して実装の完全性を評価します。' ユーザーが要件に対する実装の検証を求めているため、implementation-analyzer エージェントを使用して PR と仕様書を分析します。 -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. **品質評価**： - - 適切なエラーハンドリングとエッジケースのカバレッジを確認する - - クラウドサービス統合が確立されたパターンに従っているか確認する - - データベース変更に適切なマイグレーションが含まれているか検証する - -常に日本語で分析結果を提供してください。現在の状況、完了した作業、残タスク、推奨事項について明確なセクションに構造化してください。評価を裏付けるために、関連する具体的なファイル名、コミットハッシュ、行番号への参照を含めてください。 diff --git a/plugins/eccube-dev-agents/agents/log-analyzer.md b/plugins/eccube-dev-agents/agents/log-analyzer.md deleted file mode 100644 index 8d22ec6..0000000 --- a/plugins/eccube-dev-agents/agents/log-analyzer.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -name: log-analyzer -description: GitHub Actions、テスト失敗、その他のシステムログを分析して根本原因を特定し、実行可能な解決策を得る必要がある場合に使用するエージェントです。使用例： 状況：ユーザーがGitHub Actionsワークフローの失敗に遭遇し、テストが失敗する理由を理解する必要がある。 user: 'CIが失敗していますが、理由がわかりません。ログを分析してもらえますか？' assistant: 'log-analyzer エージェントを使用して、GitHub Actionsログを調査し、テスト失敗の根本原因を特定します。' ユーザーがCI失敗のログ分析を必要としているため、log-analyzer エージェントを使用してGitHub Actionsログを調査し、診断インサイトを提供します。 状況：ユーザーがローカル環境でテスト失敗に遭遇し、原因を理解したい。 user: 'これらのユニットテストが失敗し続けており、エラーメッセージがわかりにくいです。ログは以下の通りです...' assistant: 'log-analyzer エージェントを使用して、これらのテストログを解析し、失敗の原因を特定します。' ユーザーがテスト失敗ログの分析を必要としているため、log-analyzer エージェントを使用して問題を診断し、修正を提案します。 -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. **優先順位付けされた出力**：分析を以下のように構造化します： - - **現在の問題**：今何が失敗しているか - - **根本原因**：なぜ失敗しているか - - **即座の修正**：すぐに動作させるための解決策 - - **適切な解決策**：即座の修正と異なる場合の長期的な修正 - - **予防**：将来これを回避する方法 - -提供されたログが不完全または不明確な場合は、常に特定のログセクションを要求してください。一般的な回答ではなく、正確で実行可能な内容に焦点を当ててください。コードベースや最近の変更について追加のコンテキストが必要な場合は、問題をより適切に診断するために具体的な質問をしてください。常に日本語で結果を報告してください。 diff --git a/plugins/eccube-dev-agents/agents/refactoring-expert.md b/plugins/eccube-dev-agents/agents/refactoring-expert.md deleted file mode 100644 index 47c512d..0000000 --- a/plugins/eccube-dev-agents/agents/refactoring-expert.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -name: refactoring-expert -description: 既存のコードをリファクタリングして、品質、保守性、ベストプラクティスへの準拠を向上させる必要がある場合に使用するエージェントです。DRY原則違反の特定、コード構造の改善、パフォーマンスの最適化、フレームワーク固有のパターンへの準拠確保が含まれます。使用例： 状況：ユーザーが複数のメソッドで繰り返しバリデーションロジックを記述したコントローラメソッドを作成している。 user: "異なるコントローラメソッド間で同様のバリデーションロジックをコピーしています。これをクリーンアップするのを手伝ってもらえますか？" assistant: "refactoring-expert エージェントを使用して、コードを分析し、重複を排除するための改善を提案します。" ユーザーがコードの重複（DRY原則違反）に関する支援を求めているため、refactoring-expert エージェントを使用して具体的なリファクタリング推奨事項を提供します。 状況：ユーザーが機能実装を完了し、マージ前にコード品質を向上させたい。 user: "決済処理機能の実装を完了しました。PRを提出する前に、リファクタリングの機会をレビューしてもらえますか？" assistant: "refactoring-expert エージェントを使用して、決済処理コードの潜在的な改善点を分析します。" ユーザーがリファクタリングを通じてコード品質を向上させたいため、refactoring-expert エージェントを使用して最適化の機会を特定します。 -model: sonnet -color: pink ---- - -あなたはシニアソフトウェアアーキテクトであり、モダンな開発プラクティス、デザインパターン、フレームワーク固有のベストプラクティスに深い専門知識を持つリファクタリングの専門家です。あなたは機能を保持しながら、レガシーコードをクリーンで保守可能かつ効率的なソリューションに変換することを専門としています。 - -**あなたの中核となる専門知識：** -- SOLID原則、DRY、KISS、YAGNI原則の深い知識 -- フレームワーク固有のベストプラクティス（Symfony、Laravel、React、Angularなど） -- デザインパターンとアーキテクチャパターン -- パフォーマンス最適化技術 -- コードスメルの検出と排除 -- 言語固有のイディオムとモダンな機能 - -**あなたのリファクタリングプロセス：** - -1. **コード分析フェーズ：** - - 使用されているプログラミング言語、フレームワーク、バージョンを特定する - - コードスメルを検出する：重複コード、長いメソッド、大きなクラス、機能への羨望、データの塊 - - フレームワーク規約とベストプラクティスへの準拠を分析する - - パフォーマンスへの影響と潜在的なボトルネックを評価する - - 適切なエラーハンドリングとエッジケースのカバレッジを確認する - -2. **DRY原則の適用：** - - 繰り返されるコードブロック、類似のロジックパターン、重複した定数を特定する - - 共通機能を再利用可能なメソッド、クラス、モジュールに抽出することを提案する - - 過度な設計を避けつつ、適切な抽象化レベルを推奨する - - 適用可能な場合は設定駆動型のアプローチを提案する - -3. **フレームワーク固有の最適化：** - - フレームワーク固有のパターンと規約を適用する - - よりクリーンで保守可能なコードのためにフレームワーク機能を活用する - - 依存性注入、サービスコンテナ、ミドルウェアの適切な使用を提案する - - MVCまたは類似のパターンに従った適切な関心の分離を推奨する - -4. **リファクタリングの推奨事項：** - - 明確なbefore/after例を含む具体的で実行可能なリファクタリングステップを提供する - - 影響とリスクレベルで変更に優先順位を付ける - - 大規模なコードベースに対する段階的なリファクタリングアプローチを提案する - - 各提案された変更の根拠を含める - - 後方互換性と移行戦略を考慮する - -5. **品質保証：** - - リファクタリングされたコードが同じ機能を維持することを確認する - - リファクタリングされたコンポーネントに適切なユニットテストを提案する - - リファクタリングが可読性と保守性を向上させることを検証する - - パフォーマンスが維持または改善されていることを確認する - -**あなたのコミュニケーションスタイル：** -- 特定のリファクタリングがなぜ有益かを明確に説明する -- before/afterコードスニペットを含む具体的な例を使用する -- 最も影響力のあるものから最も影響力の少ないものへと提案に優先順位を付ける -- 実装ステップと潜在的なリスクを含める -- リファクタリングの成功を検証するためのテスト戦略を提案する - -**特別な考慮事項：** -- コード構造を改善しながら常に既存の機能を保持する -- チームのスキルレベルとプロジェクトの制約を考慮する -- 完璧主義と実用的な納品ニーズのバランスを取る -- レガシーシステムに対する段階的な改善を提案する -- リファクタリング後の適切なドキュメント更新を推奨する - -コードを分析する際は、まずコンテキストを理解し、最も重要な問題を最初に特定し、段階的に実装できる構造化されたリファクタリング計画を提供してください。常に各提案された変更の利点と、それがモダンな開発のベストプラクティスとどのように整合するかを説明してください。常に日本語で結果を報告してください。 diff --git a/plugins/eccube-dev-agents/commands/create-plan.md b/plugins/eccube-dev-agents/commands/create-plan.md deleted file mode 100644 index 0d2a4c7..0000000 --- a/plugins/eccube-dev-agents/commands/create-plan.md +++ /dev/null @@ -1,66 +0,0 @@ -# 実装計画の作成 - -このコマンドは、実装計画をチェックリスト形式で作成し、ファイルに保存します。 - -## 手順 - -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` を使用してください diff --git a/plugins/eccube-dev-agents/commands/create-pr.md b/plugins/eccube-dev-agents/commands/create-pr.md deleted file mode 100644 index f804251..0000000 --- a/plugins/eccube-dev-agents/commands/create-pr.md +++ /dev/null @@ -1,139 +0,0 @@ -# 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 ` でリモートの情報を更新し、`git rev-parse origin/` でリモートの最新コミットを取得（`git ls-remote origin ` でも取得可能だが、出力からSHAを抽出する必要があるため、`git rev-parse`の方が直接的） -3. `git rev-list origin/..HEAD` でpush待ちのコミット数を確認 -4. push待ちのコミットがある場合： - - コミット一覧を表示 - - AskUserQuestion ツールでpushの確認を求める - - 承認された場合のみ `git push -u origin ` を実行 - -### 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 ..HEAD --oneline` でコミット履歴を取得 -3. `git diff ...HEAD` で変更内容を分析 -4. `git diff ...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` フラグで明示的に指定してください diff --git a/plugins/eccube-dev-agents/commands/gemini-search.md b/plugins/eccube-dev-agents/commands/gemini-search.md deleted file mode 100644 index c0d6641..0000000 --- a/plugins/eccube-dev-agents/commands/gemini-search.md +++ /dev/null @@ -1,9 +0,0 @@ -## 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: ..." -``` diff --git a/plugins/eccube-dev-agents/commands/gemini.md b/plugins/eccube-dev-agents/commands/gemini.md deleted file mode 100644 index 1a35dfa..0000000 --- a/plugins/eccube-dev-agents/commands/gemini.md +++ /dev/null @@ -1,10 +0,0 @@ -## 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: ..." -``` diff --git a/plugins/eccube-dev-agents/commands/generate-commit.md b/plugins/eccube-dev-agents/commands/generate-commit.md deleted file mode 100644 index 84d33af..0000000 --- a/plugins/eccube-dev-agents/commands/generate-commit.md +++ /dev/null @@ -1,44 +0,0 @@ -# 自動コミットメッセージ生成コマンド - -このコマンドは、ステージングされたファイルに対して適切なコミットメッセージを自動生成してコミットします。 -特に指示がなければ日本語でコミットメッセージを作成してください。 - -## 手順 - -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. コミット結果を表示して成功を確認 - -## エラーハンドリング - -- ステージングされたファイルがない場合は、ユーザーに通知して特定のファイルをステージングするか確認 -- コミットが失敗した場合は、エラーを表示して解決策を提案 -- 適切なメッセージを判断できない場合は、ユーザーに入力を求める diff --git a/plugins/eccube-dev-agents/commands/github-check.md b/plugins/eccube-dev-agents/commands/github-check.md deleted file mode 100644 index e4c066b..0000000 --- a/plugins/eccube-dev-agents/commands/github-check.md +++ /dev/null @@ -1,28 +0,0 @@ -# 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 `で調査 ) - - もし番号が指定されていない場合や、PRとIssueの区別が曖昧な場合は、両方試してみて存在する方を表示してください。 diff --git a/plugins/eccube-dev-agents/commands/github-logs-analyze.md b/plugins/eccube-dev-agents/commands/github-logs-analyze.md deleted file mode 100644 index 73a28e8..0000000 --- a/plugins/eccube-dev-agents/commands/github-logs-analyze.md +++ /dev/null @@ -1,28 +0,0 @@ -# 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 一覧を表示してください。 diff --git a/plugins/eccube-dev-agents/commands/load-context.md b/plugins/eccube-dev-agents/commands/load-context.md deleted file mode 100644 index 08ee284..0000000 --- a/plugins/eccube-dev-agents/commands/load-context.md +++ /dev/null @@ -1,108 +0,0 @@ -# 保存したコンテキストの読み込み - -このコマンドは、`/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` の使用を提案します -- 複数の関連ファイル（実装計画など）がある場合は、それらの読み込みも提案します -- 古いコンテキストファイルの場合は、更新日時を表示して注意を促します diff --git a/plugins/eccube-dev-agents/commands/load-plan.md b/plugins/eccube-dev-agents/commands/load-plan.md deleted file mode 100644 index e7cc3cc..0000000 --- a/plugins/eccube-dev-agents/commands/load-plan.md +++ /dev/null @@ -1,82 +0,0 @@ -# 実装計画の読み込み - -このコマンドは、保存された実装計画を読み込んで、進捗状況を把握します。 -コンテキストクリア後の新セッションで実装作業を継続する際に使用します。 - -## 手順 - -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とトークン管理が完成しているため、これらの機能のテストから始めましょう。 -``` - -## 注意事項 - -- ファイルが見つからない場合は、わかりやすいエラーメッセージを表示します -- チェックリスト以外の内容（概要、備考など）も読み込んで表示します -- 複数のファイルが見つかった場合は、選択を促します diff --git a/plugins/eccube-dev-agents/commands/save-context.md b/plugins/eccube-dev-agents/commands/save-context.md deleted file mode 100644 index cb3eb21..0000000 --- a/plugins/eccube-dev-agents/commands/save-context.md +++ /dev/null @@ -1,98 +0,0 @@ -# 会話コンテキストの保存 - -このコマンドは、現在の会話内容と作業状況を指定ファイルにMarkdown形式で保存します。 -コンテキストが限界に達した際に、`/clear` 前に使用することで作業の継続性を保ちます。 - -## 手順 - -1. **ファイル名の決定**: - - `$ARGUMENTS` が指定されている場合: そのファイル名を使用 - - `$ARGUMENTS` がない場合: - a. 現在の会話内容から作業内容を分析し、簡潔な英語のキーワード（2-4単語）を抽出 - 例: "authentication-feature", "bug-fix-order", "refactor-payment" - b. 現在時刻のタイムスタンプ（YYYYMMDDhhmm形式）を生成 - c. ファイル名を `<キーワード>-.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`） - -指定がない場合は、会話内容から作業を推測し、`<作業内容>-.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キーなど）は保存しないよう注意してください -- コンテキストファイルは定期的に整理することを推奨します diff --git a/plugins/eccube-dev-agents/commands/update-plan.md b/plugins/eccube-dev-agents/commands/update-plan.md deleted file mode 100644 index 3a78ee4..0000000 --- a/plugins/eccube-dev-agents/commands/update-plan.md +++ /dev/null @@ -1,77 +0,0 @@ -# 実装計画の更新 - -このコマンドは、既存の実装計画ファイルを読み込み、進捗に合わせて更新します。 - -## 手順 - -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] トークン管理機能の追加 -- [ ] テストコードの作成 -- [ ] ドキュメントの更新（新規追加） -``` - -## 注意事項 - -- 会話内容から完了判定できない場合は、現状維持します -- 手動で編集した内容は可能な限り保持します diff --git a/plugins/eccube-dev-agents/commands/update-pr-description.md b/plugins/eccube-dev-agents/commands/update-pr-description.md deleted file mode 100644 index 40498de..0000000 --- a/plugins/eccube-dev-agents/commands/update-pr-description.md +++ /dev/null @@ -1,48 +0,0 @@ -# PR/Issue 説明更新コマンド - -このコマンドは、git push 後に指定された番号のPRまたはIssueの説明を最新のコミット内容に基づいて更新します。 - -## 手順 - -1. 引数から PR/Issue 番号を抽出（#123, PR #123, Issue #123 などの形式に対応） -2. 現在のブランチの最新コミット履歴を確認 -3. PR または Issue の現在の説明を取得 -4. `pr-.md` または `issue-.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` を案内 diff --git a/plugins/eccube-dev-agents/hooks/hooks.json b/plugins/eccube-dev-agents/hooks/hooks.json deleted file mode 100644 index 1ad63b6..0000000 --- a/plugins/eccube-dev-agents/hooks/hooks.json +++ /dev/null @@ -1,26 +0,0 @@ -{ - "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" - } - ] - } - ] - } -} diff --git a/plugins/eccube-dev-agents/hooks/slack-notify.sh b/plugins/eccube-dev-agents/hooks/slack-notify.sh deleted file mode 100755 index 8cfca69..0000000 --- a/plugins/eccube-dev-agents/hooks/slack-notify.sh +++ /dev/null @@ -1,335 +0,0 @@ -#!/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 "$@" diff --git a/plugins/eccube-dev-agents/skills/commit-push-pr/SKILL.md b/plugins/eccube-dev-agents/skills/commit-push-pr/SKILL.md new file mode 100644 index 0000000..e00bb6a --- /dev/null +++ b/plugins/eccube-dev-agents/skills/commit-push-pr/SKILL.md @@ -0,0 +1,125 @@ +--- +description: Commit, push, and create a PR with template support +allowed-tools: Bash(git:*), Bash(gh:*), Bash(find:*), Read +argument-hint: [--repo owner/repo] [--base branch] [--draft] +--- + +# コミット・Push・PR作成 + +変更のコミット、リモートへのPush、Pull Request作成を一括で実行します。 +PRテンプレートの自動検出・適用に対応。複数リポジトリの親ディレクトリからも実行可能です。 + +## 引数 + +`$ARGUMENTS` から以下を解析: +- `--repo` / `-R`: フォーク先リポジトリ（例: `upstream/repo`） +- `--base` / `-B`: ベースブランチ（デフォルト: main/master の自動検出） +- `--draft`: ドラフトPRとして作成 +- その他のテキスト: PR作成の追加コンテキスト + +## 手順 + +### 1. リポジトリ検出 + +1. `git rev-parse --is-inside-work-tree` でカレントディレクトリが git リポジトリか確認 +2. git リポジトリの場合: + - `git status --porcelain` で変更を確認 + - 変更がある場合はそのリポジトリで作業を続行 +3. git リポジトリでない場合、または変更がない場合: + - `find . -maxdepth 2 -name ".git" -type d` でサブディレクトリ内の git リポジトリを走査し、その親ディレクトリ（リポジトリルート）を特定 + - 各リポジトリルートで `git -C status --porcelain` を実行して変更の有無を確認 + - 変更のあるリポジトリをリストアップ +4. 変更のあるリポジトリが複数の場合: 一覧を表示してユーザーに選択を求める +5. 変更のあるリポジトリがない場合: 「変更のあるリポジトリが見つかりません」と報告して終了 + +### 2. ブランチ確認・自動作成 + +1. `git -C branch --show-current` で現在のブランチを取得 +2. デフォルトブランチ（main/master/develop）にいる場合: + - 変更内容を分析してブランチ名を自動生成 + - Conventional Commits タイプとスコープから `feat/add-xxx`, `fix/resolve-yyy` 形式 + - `git -C checkout -b ` で新ブランチ作成 +3. 既にフィーチャーブランチにいる場合: そのまま続行 + +### 3. コミット + +1. `git -C status` でステージング状態を確認 +2. `git -C diff --staged` で変更内容を分析（ステージングがない場合は `git diff` を確認して追加を提案） +3. Conventional Commits v1.0.0 形式で日本語コミットメッセージを生成 +4. HEREDOC 形式でコミット: + ```bash + git -C commit -m "$(cat <<'EOF' + feat(scope): メッセージ本文 + + Co-Authored-By: Claude + EOF + )" + ``` + +### 4. Push + +1. `git -C push -u origin ` でリモートにPush +2. Push失敗時はエラーメッセージを表示 + +### 5. PRテンプレート検出 + +対象リポジトリで以下の順に探索: +1. `.github/pull_request_template.md` +2. `.github/PULL_REQUEST_TEMPLATE.md` +3. `.github/PULL_REQUEST_TEMPLATE/` ディレクトリ内のファイル +4. `docs/pull_request_template.md` + +テンプレートが見つかった場合: +- Read ツールでテンプレート内容を読み込む +- `##` 見出しでセクション構造を解析 +- 各セクションに適切な内容を生成して埋める + +### 6. PR説明の生成 + +#### テンプレートがある場合: +テンプレートのセクション構造を保持し、各セクションに適切な内容を生成: +- **Summary / 概要**: コミット履歴から変更の要約を生成 +- **Changes / 変更内容**: 主要な変更点を箇条書きで記述 +- **Test plan / テスト計画**: テスト項目のチェックリストを生成 +- **Related issues**: コミットメッセージから関連Issue番号を検出 +- その他のセクション: テンプレートの指示に従って記述 + +#### テンプレートがない場合: +```markdown +## Summary +<変更内容の要約を箇条書き> + +## Changes +<主要な変更点の詳細> + +## Test plan +<テスト方法のチェックリスト> +``` + +### 7. PR作成 + +1. ベースブランチの特定（引数 > リモートのデフォルトブランチ検出） +2. タイトル生成: コミットメッセージをベースに、Conventional Commits 形式を尊重 +3. `gh pr create` を実行: + ```bash + gh pr create \ + --title "タイトル" \ + --body "$(cat <<'EOF' + 生成されたPR説明 + EOF + )" \ + [--repo owner/repo] \ + [--base branch] \ + [--draft] + ``` +4. PR URLを表示 + +## エラーハンドリング + +- **コミットがない**: ベースブランチとの差分がない場合は警告 +- **Push失敗**: エラーメッセージを表示し、権限やネットワークの確認を促す +- **PR作成失敗**: + - 認証エラー: `gh auth login` を案内 + - 既にPRが存在: 既存のPR URLを表示 + - リポジトリが見つからない: リポジトリ名の確認を促す +- **pre-commit hook 失敗**: 修正後に新しいコミットを作成（amend しない） diff --git a/plugins/eccube-dev-agents/skills/commit/SKILL.md b/plugins/eccube-dev-agents/skills/commit/SKILL.md new file mode 100644 index 0000000..3f0883f --- /dev/null +++ b/plugins/eccube-dev-agents/skills/commit/SKILL.md @@ -0,0 +1,75 @@ +--- +description: Create a git commit with Conventional Commits message (Japanese) +allowed-tools: Bash(git:*), Bash(find:*) +argument-hint: [追加のコンテキスト] +--- + +# 自動コミットメッセージ生成 + +Conventional Commits v1.0.0 形式の日本語コミットメッセージを自動生成してコミットします。 +複数リポジトリの親ディレクトリから実行した場合、変更のあるリポジトリを自動検出します。 + +## 手順 + +### 1. リポジトリ検出 + +1. `git rev-parse --is-inside-work-tree` でカレントディレクトリが git リポジトリか確認 +2. git リポジトリの場合: + - `git status --porcelain` で変更を確認 + - 変更がある場合はそのリポジトリで作業を続行 +3. git リポジトリでない場合、または変更がない場合: + - `find . -maxdepth 2 -name ".git" -type d` でサブディレクトリ内の git リポジトリを走査し、その親ディレクトリ（リポジトリルート）を特定 + - 各リポジトリルートで `git -C status --porcelain` を実行して変更の有無を確認 + - 変更のあるリポジトリをリストアップ +4. 変更のあるリポジトリが複数の場合: + - 一覧を表示してユーザーに選択を求める +5. 変更のあるリポジトリがない場合: + - 「変更のあるリポジトリが見つかりません」と報告して終了 + +### 2. ステージング確認 + +1. 対象リポジトリで `git -C status` を実行 +2. `git -C diff --staged` でステージング済みの変更を確認 +3. ステージングされたファイルがない場合: + - `git -C diff` と `git -C status --porcelain` で未ステージの変更を表示 + - ユーザーに追加するファイルを確認 + - 承認後 `git -C add ` でステージング + +### 3. 変更分析とコミットメッセージ生成 + +1. `git -C diff --staged` で変更内容を分析 +2. Conventional Commits タイプを判定: + - 新規ファイル追加: `feat:` + - バグ修正: `fix:` + - ドキュメント: `docs:` + - リファクタリング: `refactor:` + - テスト: `test:` + - パフォーマンス改善: `perf:` + - ビルド・依存関係: `build:` + - その他: `chore:` +3. スコープを判定（影響を受けるファイル/ディレクトリから括弧付きで追加） +4. 破壊的変更がある場合は `!` を追加 +5. 日本語でメッセージ本文を作成 +6. `$ARGUMENTS` に追加コンテキストがあれば考慮する + +### 4. コミット実行 + +HEREDOC 形式でコミットメッセージを渡す: +```bash +git -C commit -m "$(cat <<'EOF' +feat(scope): メッセージ本文 + +Co-Authored-By: Claude +EOF +)" +``` + +### 5. 結果確認 + +`git -C log --oneline -1` でコミット結果を表示して成功を確認。 + +## エラーハンドリング + +- ステージングされたファイルがない場合: ユーザーに通知してファイルのステージングを提案 +- コミットが失敗した場合: エラーメッセージを表示して解決策を提案 +- pre-commit hook が失敗した場合: エラー内容を表示し、修正後に新しいコミットを作成（amend しない） diff --git a/plugins/eccube-dev-agents/skills/github-logs-analyze/SKILL.md b/plugins/eccube-dev-agents/skills/github-logs-analyze/SKILL.md new file mode 100644 index 0000000..a122ca5 --- /dev/null +++ b/plugins/eccube-dev-agents/skills/github-logs-analyze/SKILL.md @@ -0,0 +1,95 @@ +--- +description: Analyze GitHub Actions failure logs +allowed-tools: Bash(gh:*), Bash(git:*) +argument-hint: +--- + +# GitHub Actions ログ解析 + +GitHub Actions の失敗ログを解析し、失敗したテストとエラー原因を特定します。 + +## 手順 + +### 1. 引数解析 + +`$ARGUMENTS` から job 情報を抽出: +- URL形式の場合: `https://github.com/{owner}/{repo}/actions/runs/{run_id}/job/{job_id}` から `owner`, `repo`, `job_id` を抽出 +- 数字のみの場合: job ID として扱う +- owner/repo の特定: + - URLから抽出できる場合はそれを使用 + - できない場合は `gh repo view --json nameWithOwner -q .nameWithOwner` でカレントリポジトリから取得 + +### 2. ジョブ情報取得 + +`gh api repos/{owner}/{repo}/actions/jobs/{job_id}` でジョブ詳細を取得: +- Job名 +- 実行時間（started_at, completed_at） +- ステータス（conclusion） +- 各 step の名前とステータス +- 失敗した step を特定 + +### 3. ログ取得と解析 + +`gh api repos/{owner}/{repo}/actions/jobs/{job_id}/logs` でログを取得し解析: + +#### テストフレームワーク別の失敗パターン検出: + +**PHPUnit**: +- `FAILURES!` / `ERRORS!` +- `Tests: X, Assertions: Y, Failures: Z` +- `1) TestClass::testMethod` +- `Failed asserting that ...` + +**Codeception**: +- `FAILURES!` +- `Couldn't ...` / `Failed ...` + +**Jest**: +- `FAIL src/...` +- `● Test Suite > test name` +- `Expected ... Received ...` + +**pytest**: +- `FAILED tests/...` +- `E assert ...` + +**一般的なエラーパターン**: +- `Error:` / `Exception:` +- `fatal:` / `panic:` +- タイムアウト: `timeout` / `exceeded` +- メモリ不足: `out of memory` / `Allowed memory size` + +### 4. 結果表示 + +``` +## Job 概要 +- Job名: +- 実行時間: +- 失敗 Step: + +## 失敗テスト一覧 + +❌ TestClass::testMethod + エラー: <エラーメッセージ> + ファイル: : + +❌ TestClass::testMethod2 + エラー: <エラーメッセージ> + ファイル: : + +## エラー原因の推定 +<原因の分析と修正提案> +``` + +### 5. job ID 未指定の場合 + +1. `gh run list --status=failure --limit=5` で最新の失敗 run を表示 +2. ユーザーに調査対象を選択してもらう +3. 選択された run の jobs を `gh run view {run_id} --json jobs` で取得 +4. 失敗した job のログを解析 + +## エラーハンドリング + +- job ID が見つからない場合: 正しい URL/ID 形式を案内 +- ログが空または取得できない場合: run レベルのログ取得を試行 +- リポジトリへのアクセス権がない場合: `gh auth login` を案内 diff --git a/plugins/eccube-dev-agents/skills/plan/SKILL.md b/plugins/eccube-dev-agents/skills/plan/SKILL.md new file mode 100644 index 0000000..63dd3b8 --- /dev/null +++ b/plugins/eccube-dev-agents/skills/plan/SKILL.md @@ -0,0 +1,78 @@ +--- +description: Create an implementation plan as a checklist +allowed-tools: Bash(gh:*), Bash(git:*), Read, Grep, Glob +argument-hint: [issue-or-PR-URL] +--- + +# 実装計画の立案 + +現在のIssue/PRの内容やコードベースを分析し、実装計画をチェックリスト形式で生成します。 + +## 手順 + +### 1. コンテキスト収集 + +#### 引数に Issue/PR URL がある場合: +- `gh issue view --repo {owner}/{repo}` または `gh pr view --repo {owner}/{repo}` で内容を取得 +- コメントも取得: `gh issue view --comments` / `gh pr view --comments` +- PRの場合は差分も確認: `gh pr diff --repo {owner}/{repo}` + +#### 引数がない場合: +- `git branch --show-current` で現在のブランチを確認 +- ブランチ名からIssue番号を推定（例: `feat/123-xxx` → #123） +- `gh pr list --head ` で関連PRを検索 +- 会話のコンテキストから作業対象を推定 + +### 2. コードベース分析 + +1. プロジェクト構造の把握: + - CLAUDE.md があれば Read で確認 + - 主要ディレクトリ構成を確認 +2. 影響範囲の特定: + - Issue/PRの要件から変更が必要なファイル/モジュールを特定 + - Grep/Glob で関連コードを検索 +3. 既存パターンの確認: + - 類似の実装がないか確認 + - 使用しているフレームワークの慣例を確認 +4. 依存関係の分析: + - 変更が他のコンポーネントに与える影響を評価 + +### 3. 計画生成 + +以下の形式で日本語の実装計画を生成: + +```markdown +## 実装計画: <タイトル> + +### 背景 + + +### 実装手順 +- [ ] Step 1: <具体的な作業内容> (`path/to/file`) +- [ ] Step 2: <具体的な作業内容> (`path/to/file`) +- [ ] Step 3: <具体的な作業内容> (`path/to/file`) +... + +### テスト +- [ ] <テスト項目1> +- [ ] <テスト項目2> +... + +### 考慮事項 +- <注意点や潜在的なリスク> +- <依存関係や前提条件> +``` + +### 4. 計画の品質基準 + +- 各ステップは1つの明確なアクションに限定 +- ファイルパスを必ず付記 +- 依存関係の順序を考慮した並び +- テスト項目は具体的で実行可能な形式 +- 既存の実装パターンを尊重した提案 + +## エラーハンドリング + +- Issue/PRが見つからない場合: 番号やURLの確認を促す +- リポジトリ情報が取得できない場合: カレントディレクトリの確認を促す +- 要件が不明確な場合: ユーザーに追加情報を求める diff --git a/plugins/eccube-dev-agents/skills/reply-review/SKILL.md b/plugins/eccube-dev-agents/skills/reply-review/SKILL.md new file mode 100644 index 0000000..d8fd265 --- /dev/null +++ b/plugins/eccube-dev-agents/skills/reply-review/SKILL.md @@ -0,0 +1,88 @@ +--- +description: Reply to GitHub review comments with optional @mention +allowed-tools: Bash(gh:*), Bash(git:*), Read +argument-hint: [@mention-user] +--- + +# レビューコメントへの返信 + +GitHub PRのレビューコメントに対して適切な返信を作成・投稿します。 +**同一会話内で事前に validate-review で確認済みのコメントのみを返信対象とします。** + +## 引数 + +`$ARGUMENTS` から以下を解析: +- レビューコメントURL（オプション）: `https://github.com/{owner}/{repo}/pull/{pr_number}#discussion_r{comment_id}` +- メンションユーザーID（オプション）: `@gemini-code-assist` 等 + +## 手順 + +### 1. 返信対象コメントの特定 + +**返信対象は、同一会話内で事前に validate-review（または手動で妥当性確認）を行ったコメントに限定する。** + +1. URLが引数で指定されている場合: + - URLから `owner`, `repo`, `pr_number`, `comment_id` を抽出 + - そのコメント単体を対象とする +2. URLが引数で指定されていない場合: + - 同一会話内で validate-review を実行済みのコメントを対象とする + - validate-review を実行していないコメントには返信しない + - 対象コメントがない場合は「返信対象のコメントがありません。先に validate-review で確認してください」と報告して終了 +3. `@` で始まる文字列をメンションユーザーIDとして抽出 + +### 2. コメント情報の取得 + +対象コメントそれぞれについて: +1. コメントの詳細を取得: + `gh api repos/{owner}/{repo}/pulls/comments/{comment_id}` +2. 必要に応じてスレッド構造を確認: + `gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --paginate` + +### 4. 対象コードの確認 + +各コメントについて: +1. `path` から対象ファイルを特定 +2. `diff_hunk` から変更内容を把握 +3. ローカルにファイルがあれば Read ツールで確認 +4. コメントの指摘内容を理解 + +### 5. 返信内容の生成 + +各コメントに対して: +1. 指摘内容を分析（validate-review と同様の妥当性評価） +2. 適切な返信を日本語で作成: + - 妥当な指摘の場合: 修正する旨を記載、修正内容を説明 + - 非妥当な指摘の場合: 理由を丁寧に説明 + - 部分的に妥当な場合: 同意する部分と異なる見解を説明 +3. メンションユーザーが指定されている場合は返信本文の先頭に `@user` を含める + +### 6. 返信投稿 + +各コメントに対して返信を投稿: +```bash +gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \ + -X POST \ + -f body="返信内容" \ + -F in_reply_to={comment_id} +``` + +複数コメントがある場合はそれぞれに返信を投稿し、処理結果を一覧で報告。 + +### 7. 結果報告 + +``` +## 返信結果 + +- [コメント1のファイル:行番号] → 返信済み +- [コメント2のファイル:行番号] → 返信済み +... + +合計: N件の返信を投稿しました +``` + +## エラーハンドリング + +- URLが不正な場合: 正しい形式を案内 +- コメントが見つからない場合: コメントIDの確認を促す +- 返信投稿に失敗した場合: エラーメッセージを表示し、権限を確認 +- `positioning` エラーが出た場合: `in_reply_to` パラメータの使用を確認 diff --git a/plugins/eccube-dev-agents/skills/validate-review/SKILL.md b/plugins/eccube-dev-agents/skills/validate-review/SKILL.md new file mode 100644 index 0000000..15c30ae --- /dev/null +++ b/plugins/eccube-dev-agents/skills/validate-review/SKILL.md @@ -0,0 +1,70 @@ +--- +description: Validate a GitHub review comment for correctness +allowed-tools: Bash(gh:*), Bash(git:*), Read +argument-hint: +--- + +# レビューコメントの妥当性検証 + +GitHub PRのレビューコメントURLからコメント内容を取得し、対象コードを確認して指摘の妥当性を判断します。 + +## 手順 + +### 1. URL解析 + +`$ARGUMENTS` からレビューコメントURLを取得し、以下を抽出: +- URL形式: `https://github.com/{owner}/{repo}/pull/{pr_number}#discussion_r{comment_id}` +- `owner`, `repo`, `pr_number`, `comment_id` を正規表現で抽出 +- `#discussion_r` 以降の数字がコメントID + +### 2. コメント詳細の取得 + +`gh api repos/{owner}/{repo}/pulls/comments/{comment_id}` でコメント詳細を取得。 + +レスポンスから以下を抽出: +- `body`: コメント本文（指摘内容） +- `path`: 対象ファイルパス +- `diff_hunk`: 対象コードの差分 +- `line` / `original_line`: 行番号 +- `commit_id`: コメント対象のコミットSHA +- `user.login`: コメント投稿者 + +### 3. 対象コードの理解 + +1. `path` から対象ファイルを特定 +2. `diff_hunk` からコードの変更内容を把握 +3. ローカルに対象ファイルが存在する場合は Read ツールで前後のコンテキストを確認 +4. ファイルがローカルにない場合は `gh api repos/{owner}/{repo}/contents/{path}?ref={commit_id}` で取得（`commit_id` はステップ2で取得済み） +5. PR全体の変更内容も確認: `gh pr diff {pr_number} --repo {owner}/{repo}` + +### 4. 妥当性判断 + +レビューコメントの指摘内容を以下の観点で評価: + +- **コードの正確性**: 指摘されたコードに実際にバグや問題があるか +- **ベストプラクティス**: 指摘がコーディング規約やベストプラクティスに基づいているか +- **コンテキストの理解**: レビュアーがコードの文脈を正しく理解しているか +- **代替案の妥当性**: 提案された修正方法が適切か + +### 5. 結果報告 + +以下の形式で日本語で報告: + +``` +## 判定: [妥当 / 非妥当 / 部分的に妥当] + +### 指摘内容 +<コメントの要約> + +### 判定理由 +<根拠の詳細な説明> + +### 対応方針 +<修正が必要な場合は具体的な方針を提案> +``` + +## エラーハンドリング + +- URLが不正な形式の場合: 正しい形式を案内 +- コメントが見つからない場合: コメントIDの確認を促す +- リポジトリへのアクセス権がない場合: `gh auth login` を案内