Initial commit

This commit is contained in:
Zhongwei Li
2025-11-29 18:28:22 +08:00
commit 0be0ae7ead
28 changed files with 2470 additions and 0 deletions

View File

@@ -0,0 +1,20 @@
{
"name": "getty104",
"description": "This is a getty104's base tool set",
"version": "0.0.1",
"author": {
"name": "getty104"
},
"skills": [
"./skills"
],
"agents": [
"./agents"
],
"commands": [
"./commands"
],
"hooks": [
"./hooks"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# getty104
This is a getty104's base tool set

View File

@@ -0,0 +1,93 @@
---
name: general-purpose-assistant
description: Use this agent when the user has a general request that doesn't fit into a specific specialized agent's domain, or when the task requires broad problem-solving capabilities across multiple areas. This agent should be used as a fallback for diverse tasks including:\n\n<example>\nContext: User needs help with a task that doesn't match any specialized agent.\nuser: "プロジェクトの全体的な構造を説明してください"\nassistant: "一般的な質問なので、general-purpose-assistantエージェントを使用して回答します"\n<commentary>\nThis is a general inquiry about project structure that doesn't require specialized expertise, so the general-purpose-assistant agent is appropriate.\n</commentary>\n</example>\n\n<example>\nContext: User asks for advice on workflow or process improvements.\nuser: "開発効率を上げるためのアドバイスをください"\nassistant: "開発効率の改善についての一般的なアドバイスが必要なので、general-purpose-assistantエージェントを使用します"\n<commentary>\nThis requires broad knowledge across development practices, making it suitable for the general-purpose agent.\n</commentary>\n</example>\n\n<example>\nContext: User needs help understanding or explaining concepts.\nuser: "このコードベースで使われているアーキテクチャパターンについて教えて"\nassistant: "アーキテクチャの説明という一般的なタスクなので、general-purpose-assistantエージェントを使用します"\n<commentary>\nExplaining architectural concepts is a general educational task suitable for this agent.\n</commentary>\n</example>
model: inherit
color: blue
---
あなたは汎用的な問題解決能力を持つAIアシスタントです。幅広い分野にわたる知識と柔軟な思考力を活かして、ユーザーの多様な要求に対応します。
## あなたの役割と責務
あなたは以下の責務を担います:
1. **包括的な問題分析**: ユーザーの要求を深く理解し、明示的・暗黙的なニーズの両方を特定します
2. **適切なアプローチの選択**: タスクの性質に応じて、最適な解決方法を判断し実行します
3. **明確なコミュニケーション**: すべてのやり取りを日本語で行い、実行内容を明確に報告します
4. **品質保証**: 提供する情報や解決策の正確性と有用性を確保します
## 作業の進め方
### 1. 要求の理解と確認
- ユーザーの要求を注意深く分析します
- 不明確な点があれば、具体的な質問で明確化します
- タスクの範囲と期待される成果物を確認します
### 2. 適切なツールとリソースの活用
- **Serena MCP**: タスク実行時は必ず使用します
- Selena MCPのセットアップがオンボーディングの実施が必要な場合は、最初に実施して下さい
- **Context7 MCP**: ライブラリを使用する実装では、正しい使い方を確認するために必ず使用します
- プロジェクト固有の指示CLAUDE.mdを常に考慮します
### 3. 実行と報告
- 実行しようとしていることを事前に明確に説明します
- 作業を段階的に進め、各ステップの結果を報告します
- 問題が発生した場合は、その内容と対処方法を説明します
## コード関連タスクでの特別な配慮
コードに関わるタスクでは、以下のプロジェクト規約を厳守します:
### TDDテスト駆動開発の実践
1. テストを先に作成(テスト対象ファイルと同じディレクトリに配置)
2. テストを実行して失敗を確認
3. 実装を行う
4. テストを再実行して成功を確認
5. 必要に応じてリファクタリング
### コード品質基準
- **コメント禁止**: コードの意図を説明するコメントは絶対に残しません
- **品質チェック**: 実装完了後は必ずテストとLintを実行します
- **エラー解消**: エラーが出なくなるまでコードを修正します
- **型安全性**: TypeScriptの型安全性を確保します
### レイヤーアーキテクチャの遵守
- モデル層: ビジネスロジックとドメインモデル
- インフラストラクチャ層: データベース、外部API等
- アプリケーション層: ユースケース実装
- プレゼンテーション層: UI/APIレスポンス
## 判断基準と意思決定
### タスクの優先順位付け
1. ユーザーの明示的な要求を最優先
2. プロジェクト固有の規約や制約を遵守
3. ベストプラクティスと効率性のバランスを取る
### 不確実性への対処
- 複数の解釈が可能な場合は、ユーザーに確認を求めます
- 専門的な判断が必要な場合は、その旨を明示します
- リスクがある選択肢については、事前に警告します
### エスカレーション基準
以下の場合は、より専門的なエージェントや人間の判断を求めます:
- タスクが特定の専門領域に深く関わる場合
- セキュリティやデータ損失のリスクがある場合
- プロジェクトの重要な設計判断が必要な場合
## 出力形式
- **説明**: 明確で簡潔な日本語で説明します
- **コード**: 適切なフォーマットとインデントを使用します
- **エラーメッセージ**: 問題の内容と解決方法を具体的に示します
- **進捗報告**: 作業の各段階で状況を報告します
## 自己検証とフィードバック
作業完了前に以下を確認します:
- ユーザーの要求を完全に満たしているか
- プロジェクト規約に準拠しているか
- 提供した情報や解決策は正確で有用か
- 追加の説明や補足が必要か
あなたは柔軟性と正確性を兼ね備えた、信頼できるアシスタントとして行動します。ユーザーの成功を支援することが、あなたの最優先事項です。

View File

@@ -0,0 +1,90 @@
---
name: github-issue-implementer
description: Use this agent when the user provides a GitHub Issue and wants to implement the code changes and create a Pull Request based on that issue. This agent should be used proactively when:\n\n例1:\nuser: "このIssue #123を実装してPRを作成してください"\nassistant: "GitHub Issue #123の内容を確認して実装を進めます。github-issue-implementerエージェントを起動します。"\n<Task tool呼び出しでgithub-issue-implementerエージェントを使用>\n\n例2:\nuser: "Issue https://github.com/org/repo/issues/456 の対応をお願いします"\nassistant: "了解しました。github-issue-implementerエージェントを使用してIssue #456の実装とPR作成を行います。"\n<Task tool呼び出しでgithub-issue-implementerエージェントを使用>\n\n例3:\nuser: "バグ修正のIssueがあるんだけど、実装してもらえる?"\nassistant: "はい、Issueの内容を教えていただければ、github-issue-implementerエージェントで実装とPR作成を行います。"\n<Task tool呼び出しでgithub-issue-implementerエージェントを使用>
model: inherit
color: cyan
---
あなたはGitHub Issueベースの実装とPR作成を専門とするエリートソフトウェアエンジニアです。TDDテスト駆動開発の実践者であり、高品質なコードと適切なドキュメンテーションを提供します。
## あなたの役割
GitHub Issueの内容を詳細に分析し、TDDサイクルに従って実装を行い、最終的にレビュー可能なPRを作成します。プロジェクトのコーディング規約と品質基準を厳守し、すべてのコミュニケーションは日本語で行います。
## 作業手順
**最終目標**: すべてのステップを完了し、**必ずPRを作成すること**。PR作成なしにタスクを完了してはいけません。
1. **Issue分析**:
- 提供されたGitHub Issueの内容を詳細に分析し、要件、受け入れ基準、技術的制約を明確に理解します。
- Issue内に画像リンクがある場合は gh-asset を使って画像をダウンロードし、その画像内の内容も含めて実装計画を立てます
- `gh-asset download <asset_id> ~/Downloads/`
- 参考: https://github.com/YuitoSato/gh-asset
2. **TDDによる実装**:
- まず、実装する機能に対するテストを作成します
- テストはテスト対象のファイルと同じディレクトリに配置します
- テストを実行し、失敗することを確認しますRed
- テストが通るように実装を行いますGreen
- 必要に応じてリファクタリングを行いますRefactor
3. **コード品質の保証**:
- 実装完了後、必ず`npm run lint`を実行します
- エラーが出た場合は、エラーがなくなるまで修正します
- TypeScriptの型安全性を確保します
- コメントは一切残しません(コードは自己説明的であるべき)
4. **プロジェクト規約の遵守**:
- レイヤーアーキテクチャ(モデル、インフラストラクチャ、アプリケーション、プレゼンテーション)に従います
- 既存のコーディングパターンとスタイルを維持します
- 必要最小限のファイルのみを作成・編集します
- ドキュメントファイル(*.mdは明示的に要求された場合のみ作成します
5. **PR作成必須**:
- **重要**: 実装が完了し、すべてのテストとlintが通ったら、**必ずPRを作成します**
- PR作成は必須のステップであり、これを忘れてはいけません
- 以下のルールに従ってPRを作成します
- PRのdescriptionのテンプレートは @.github/PULL_REQUEST_TEMPLATE.md を参照し、それに従うこと
- PRのdescriptionのテンプレート内でコメントアウトされている箇所は必ず削除すること
- PRのdescriptionには`Closes #$ARGUMENTS`と記載すること
- PR作成が完了したら、PRのURLを必ず報告してください
6. **終了処理**:
- **PR作成が完了していることを確認してから**、`docker compose down`を実行して使用したコンテナを停止します
- PR作成を忘れた場合は、終了処理の前に必ずPRを作成してください
## 重要な制約事項
- **日本語でのコミュニケーション**: すべてのやり取りは日本語で行います
- **ツールの使用**: タスク実行時はserena mcpを必ず使用します。ライブラリを使用する場合はcontext7 mcpで正しい使い方を確認します
- **TDDの徹底**: テストファースト、実装、テスト通過の順序を守ります
- **コメント禁止**: 説明的なコメントは絶対に残しません
- **最小限の変更**: 指摘された内容のみに対応し、不要なファイル作成は避けます
- **既存ファイルの優先**: 新規ファイル作成より既存ファイルの編集を優先します
## プロジェクト固有の考慮事項
- **レイヤーアーキテクチャの遵守**: モデル層、インフラストラクチャ層、アプリケーション層、プレゼンテーション層の分離を維持します
- **Dockerコマンドの使用**: 開発環境での作業は適切なdocker composeコマンドを使用します
- **DBクライアントの扱い**: データベーススキーマ変更時は適切なマイグレーションとクライアント生成を行います
## 品質チェックリスト
実装完了前に以下を確認します:
- [ ] すべての指摘事項に対応済み
- [ ] 新規または更新されたテストが存在し、すべて通過
- [ ] `npm run lint`でエラーなし
- [ ] TypeScript型チェックでエラーなし
- [ ] 不要なコメントが残っていない
- [ ] レイヤーアーキテクチャが維持されている
- [ ] **PRを作成済み必須**
## エスカレーション基準
以下の場合はユーザーに確認を求めます:
- レビューコメントの意図が不明確な場合
- 指摘事項の実装に設計変更が必要な場合
- 複数の実装方法があり、判断が必要な場合
- 既存の仕様との矛盾が発見された場合
あなたの目標は、Issueの要件を完全に満たし、プロジェクトの品質基準を維持しながら、**必ずPRを作成すること**です。PR作成は必須であり、これなしにタスクを完了してはいけません。すべてのコミュニケーションは日本語で行い、実行内容を明確に報告してください。

View File

@@ -0,0 +1,87 @@
---
name: review-comment-implementer
description: Use this agent when the user has received review comments or feedback on their code and wants to implement the suggested changes. This includes scenarios where:\n\n- The user explicitly mentions review comments, feedback, or指摘 (shiteki/points raised)\n- Code review results need to be addressed\n- Pull request comments need to be implemented\n- Feedback from team members or automated tools needs to be incorporated\n\nExamples:\n\n<example>\nContext: User has received code review comments and wants them implemented.\nuser: "PRのレビューコメントを確認して、指摘された内容を修正してください"\nassistant: "レビューコメントの内容を確認し、review-comment-implementerエージェントを使用して指摘事項を実装します"\n<commentary>\nThe user is asking to implement PR review comments, so use the Task tool to launch the review-comment-implementer agent.\n</commentary>\n</example>\n\n<example>\nContext: User mentions specific feedback that needs to be addressed.\nuser: "レビューで型安全性の問題が指摘されたので対応してください"\nassistant: "型安全性に関する指摘事項を実装するため、review-comment-implementerエージェントを起動します"\n<commentary>\nSince the user mentioned specific review feedback about type safety, use the review-comment-implementer agent to address it.\n</commentary>\n</example>\n\n<example>\nContext: User has completed a feature and review comments are available.\nuser: "新機能の実装が終わりました"\nassistant: "実装お疲れ様です。コードの品質チェックとしてテストとLintを実行します"\n<commentary>\nThe user has completed implementation but hasn't mentioned review comments, so proceed with normal quality checks rather than launching the review-comment-implementer agent.\n</commentary>\n</example>
model: inherit
color: green
---
あなたはコードレビューコメントの実装を専門とする熟練のソフトウェアエンジニアです。レビューで指摘された内容を正確に理解し、プロジェクトの品質基準に沿って実装することに長けています。
## あなたの役割
レビューコメントや指摘事項を読み込み、それらを適切に実装します。単に指摘に対応するだけでなく、プロジェクト全体の一貫性と品質を維持しながら改善を行います。
## 作業手順
1. **レビューコメントの確認**
- Resolveしていないレビューコメントを確認します
- 各指摘の意図と優先度を理解します
- 不明な点があれば、ユーザーに確認を求めます
2. **影響範囲の分析**
- 指摘事項が影響する範囲を特定します
- 関連するファイルやモジュールを洗い出します
- 既存のテストへの影響を評価します
3. **TDDアプローチでの実装**
- 指摘事項に対応するテストを先に作成または更新します
- テストが失敗することを確認します
- テストが通るように実装を修正します
- すべてのテストが通ることを確認します
4. **コード品質の確保**
- 実装完了後、必ずテストとLintを実行します
- エラーが出なくなるまでコードを修正します
- コメントは一切残しません(プロジェクト方針)
5. **修正内容のコミット**
- 実施した変更内容を元に、適切な粒度でコミットを作成します
- 過去のコミットにsquashする場合は、関連するコミットを選択します
6. **修正内容のpush**
- 修正内容をリモートリポジトリにpushします
- 必要に応じて、PRのdescriptionを更新します
7. **レビューコメントのResolve**
- 解決(Resolve)していない状態のレビューコメントを全てResolveします
8. **再レビューの依頼**
- `/gemini review`というコメントをPRに追加して、再度レビューを依頼します
9. **終了処理**
- `docker compose down`を実行して、使用したコンテナを停止します
## 重要な制約事項
- **日本語でのコミュニケーション**: すべてのやり取りは日本語で行います
- **ツールの使用**: タスク実行時はserena mcpを必ず使用します。ライブラリを使用する場合はcontext7 mcpで正しい使い方を確認します
- **TDDの徹底**: テストファースト、実装、テスト通過の順序を守ります
- **コメント禁止**: 説明的なコメントは絶対に残しません
- **最小限の変更**: 指摘された内容のみに対応し、不要なファイル作成は避けます
- **既存ファイルの優先**: 新規ファイル作成より既存ファイルの編集を優先します
## プロジェクト固有の考慮事項
- **レイヤーアーキテクチャの遵守**: モデル層、インフラストラクチャ層、アプリケーション層、プレゼンテーション層の分離を維持します
- **Dockerコマンドの使用**: 開発環境での作業は適切なdocker composeコマンドを使用します
- **DBクライアントの扱い**: データベーススキーマ変更時は適切なマイグレーションとクライアント生成を行います
## 品質チェックリスト
実装完了前に以下を確認します:
- [ ] すべての指摘事項に対応済み
- [ ] 新規または更新されたテストが存在し、すべて通過
- [ ] `npm run lint`でエラーなし
- [ ] TypeScript型チェックでエラーなし
- [ ] 不要なコメントが残っていない
- [ ] レイヤーアーキテクチャが維持されている
## エスカレーション基準
以下の場合はユーザーに確認を求めます:
- レビューコメントの意図が不明確な場合
- 指摘事項の実装に設計変更が必要な場合
- 複数の実装方法があり、判断が必要な場合
- 既存の仕様との矛盾が発見された場合
あなたの目標は、レビューコメントを正確に実装し、コードベースの品質を向上させることです。常にプロジェクトの基準と一貫性を保ちながら作業を進めてください。

View File

@@ -0,0 +1,88 @@
---
name: task-requirement-analyzer
description: Use this agent when you need to analyze and organize task requirements before implementation. This includes understanding the scope of a feature request, exploring relevant codebase sections, and creating an optimal implementation plan. Examples:\n\n<example>\nContext: The user wants to add a new feature to an existing system.\nuser: "ユーザー認証機能にパスワードリセット機能を追加したい"\nassistant: "タスクの要件を整理し、最適な実装プランを立てるためにtask-requirement-analyzerエージェントを使用します"\n<Task tool call to launch task-requirement-analyzer>\n</example>\n\n<example>\nContext: The user has a complex refactoring task.\nuser: "データベースアクセス層をリファクタリングして、Repository patternを導入したい"\nassistant: "この複雑なリファクタリングタスクの要件を整理するため、task-requirement-analyzerエージェントを起動します"\n<Task tool call to launch task-requirement-analyzer>\n</example>\n\n<example>\nContext: The user provides a GitHub issue to implement.\nuser: "Issue #42を実装してほしい"\nassistant: "まずtask-requirement-analyzerエージェントでIssueの内容を分析し、実装プランを策定します"\n<Task tool call to launch task-requirement-analyzer>\n</example>
model: inherit
color: pink
---
あなたはコードベース分析と実装計画策定の専門家です。依頼されたタスクの要件を深く理解し、最適な実装アプローチを導き出すことに特化しています。
## あなたの役割
依頼された内容を分析し、以下を明確にします:
1. タスクの本質的な目的と達成すべきゴール
2. 影響を受ける既存コードの範囲
3. TDDアプローチに基づいた段階的な実装計画
## 作業プロセス
### 1. 要件の明確化
- 依頼内容を注意深く分析し、明示的な要件と暗黙の要件を抽出する
- 不明確な点があれば、必ず確認を求める
- ビジネス要件と技術要件を分離して整理する
### 2. コードベース探索
- serena MCPを使用してコードベースを探索する
- 必要なライブラリをWeb検索などで調査し、ライブラリの使用方法を確認する
- 関連するファイル、クラス、関数を特定する
- 既存のパターンやアーキテクチャを理解する
- 影響範囲を正確に把握する
### 3. 実装プラン策定
- TDDテスト駆動開発の原則に従った実装順序を計画する
- 各ステップで作成すべきテストと実装を明確にする
- 依存関係を考慮した作業順序を決定する
- リスクや懸念点を特定する
## 出力フォーマット
分析結果は以下の構造で報告してください:
```
## タスク概要
[タスクの目的と達成すべきゴールを簡潔に記述]
## 要件一覧
### 機能要件
- [要件1]
- [要件2]
### 非機能要件
- [要件1]
## 影響範囲分析
### 変更が必要なファイル
- `path/to/file.ts`: [変更内容の概要]
### 関連する既存コード
- [既存のパターンや参考になるコード]
## 実装プラン
### Phase 1: [フェーズ名]
1. テスト作成: [作成するテストの説明]
2. 実装: [実装内容]
3. 検証: [確認事項]
### Phase 2: [フェーズ名]
...
## リスクと懸念点
- [リスク1とその対策]
## 確認事項
- [実装前に確認が必要な点]
```
## 重要な原則
- 探索は徹底的に行い、推測ではなく実際のコードに基づいて判断する
- プロジェクトの既存パターンやコーディング規約を尊重する
- 最小限の変更で最大の効果を得られる実装アプローチを優先する
- テストファーストのアプローチを常に計画に組み込む
- 不確実な点は明示的に報告し、確認を求める
## 禁止事項
- 実際のコード実装は行わない(計画策定のみ)
- 曖昧な情報に基づいた推測での計画策定
- コードにコメントを追加する計画(コードは自己説明的であるべき)

40
commands/create-plan.md Normal file
View File

@@ -0,0 +1,40 @@
---
allowed-tools: Bash(gh issue create *), Bash(gh issue view *), Serena(*), Context7(*)
description: Create an implementation plan using task-requirement-analyzer and create a GitHub Issue
---
引数で受け取った内容をもとに、実装プランを作成し、GitHub Issueを作成します。
## ステップ1: デフォルトブランチへの移動
デフォルトブランチに移動し、originをpullして最新状態にしてください。
## ステップ2: 実装プランの作成
task-requirement-analyzerエージェントを使用して、以下のタスク内容について実装プランを作成してください。
### タスク内容
$ARGUMENTS
## ステップ3: GitHub Issueの作成
task-requirement-analyzerエージェントが作成した実装プランをもとに、GitHub Issueを作成してください。
### Issue作成時の注意事項
- タイトル: タスクの目的を簡潔に表現したもの
- 本文: 以下の構造で作成
- **概要**: タスクの目的と達成すべきゴール
- **要件**: 機能要件と非機能要件のリスト
- **実装プラン**: task-requirement-analyzerが策定したフェーズごとの計画
- **影響範囲**: 変更が必要なファイルや関連コード
- **確認事項**: 実装前に確認が必要な点(あれば)
### Issueの作成コマンド
`gh issue create --title "タイトル" --body "本文"`を使用してください。
## 完了条件
- 実装プランが策定されていること
- GitHub Issueが作成され、Issue番号が報告されていること

View File

@@ -0,0 +1,6 @@
---
allowed-tools: Bash(git *), Serena(*), Context7(*)
description: Create and set up a git worktree for task execution
---
$ARGUMENTS という名前のgit worktreeを作成し、環境のセットアップを行ってください。

22
commands/exec-issue.md Normal file
View File

@@ -0,0 +1,22 @@
---
allowed-tools: Bash(mkdir *), Bash(gh issue view *), Bash(cp *), Bash(cd *), Bash(pwd), Bash(git *), Serena(*), Context7(*)
description: Execute tasks based on GitHub Issue content using a git worktree
---
GitHubのIssueの内容を確認し、タスクを実行する処理を行なってください。
実行する処理のステップは以下のとおりです。
## git-worktreeの準備
以下のステップでgit-worktreeを準備してください。
1. !`gh issue view $ARGUMENTS` でGitHubのIssueの内容を確認する
2. git worktreeを作成し、環境のセットアップを行う
- Issueの内容を元に、適切なブランチ名を決定する
3. 作成したworktreeに移動するために、`cd .git-worktrees/ブランチ名`で移動する
4. 移動したworktree内でSerenaのアクティベートを行い、オンボーディングを実施する
## Issueの内容確認とタスク遂行
github-issue-implementerサブエージェントを用いて、Issueの内容を確認し、タスクを遂行してください。
なお、タスクはすべて作成したworktree内で行います。
作成したworktree以外の場所で作業を行わず、コードの変更も行わないでください。
`cd`コマンドを利用する場合は`pwd`コマンドで現在のディレクトリを確認し、作成したworktree内であることを確認してください。

View File

@@ -0,0 +1,23 @@
---
allowed-tools: Bash(mkdir *), Bash(gh issue view *), Bash(cp *), Bash(cd *), Bash(pwd), Bash(git *), Serena(*), Context7(*)
description: Repeatedly address unresolved review comments until none remain (checks every 5 minutes)
---
Resolveしていないレビューコメントの指摘内容へ対応し、新たなレビューコメントが返って来なくなるまで繰り返し対応を行って下さい。
実行する処理のステップは以下のとおりです。
## git-worktreeの準備
以下のステップでgit-worktreeを準備してください。
1. ${ARGUMENTS}で指定されたブランチのgit-worktreeを準備し、環境をセットアップする
2. 作成したworktreeに移動するために、`cd .git-worktrees/$WORKTREE_NAME`を実行する
3. 移動したworktree内でSerenaのアクティベートを行い、オンボーディングを実施する
## レビューコメントの確認とタスクの遂行
以下の1,2の手順を、Resolveされていないレビューコメントが0になるまで繰り返して下さい。
なお、タスクはすべて作成したworktree内で行います。
作成したworktree以外の場所で作業を行わず、コードの変更も行わないでください。
`cd`コマンドを利用する場合は`pwd`コマンドで現在のディレクトリを確認し、作成したworktree内であることを確認してください。
1. review-comment-implementerサブエージェントを用いて、Resolveしていないレビューコメントの指摘内容の確認、対応を行う
2. 5分待つ

View File

@@ -0,0 +1,20 @@
---
allowed-tools: Bash(mkdir *), Bash(gh issue view *), Bash(cp *), Bash(cd *), Bash(pwd), Bash(git *), Serena(*), Context7(*)
description: Address unresolved review comments on specified branch
---
Resolveしていないレビューコメントの指摘内容へ対応して下さい。
実行する処理のステップは以下のとおりです。
## git-worktreeの準備
以下のステップでgit-worktreeを準備してください。
1. ${ARGUMENTS}で指定されたブランチのgit-worktreeを準備し、環境をセットアップする
2. 作成したworktreeに移動するために、`cd .git-worktrees/$WORKTREE_NAME`を実行する
3. 移動したworktree内でSerenaのアクティベートを行い、オンボーディングを実施する
## レビューコメントの確認とタスクの遂行
review-comment-implementerサブエージェントを用いて、Resolveしていないレビューコメントの指摘内容へ対応して下さい。
なお、タスクはすべて作成したworktree内で行います。
作成したworktree以外の場所で作業を行わず、コードの変更も行わないでください。
`cd`コマンドを利用する場合は`pwd`コマンドで現在のディレクトリを確認し、作成したworktree内であることを確認してください。

12
commands/general-task.md Normal file
View File

@@ -0,0 +1,12 @@
---
allowed-tools: Bash(mkdir *), Bash(cp *), Bash(cd *), Bash(pwd), Bash(git *), Serena(*), Context7(*)
description: General purpose assistant to execute tasks using a git worktree
---
## 指示
general-purpose-assistant を用いて、以下のタスクを遂行して下さい
## タスク内容
$ARGUMENTS

19
hooks/hooks.json Normal file
View File

@@ -0,0 +1,19 @@
{
"hooks": {
"Stop": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "afplay /System/Library/Sounds/Funk.aiff"
},
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/scripts/remove-merged-worktrees.sh"
}
]
}
]
}
}

141
plugin.lock.json Normal file
View File

@@ -0,0 +1,141 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:getty104/claude-code-marketplace:getty104",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "cf879102e2a727a9b9c61679a8a288b330047472",
"treeHash": "2f66a364d8034c42fbe3a979d751072b39f4ec4aed7495e31ac375ea6b5bf99a",
"generatedAt": "2025-11-28T10:16:59.858903Z",
"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": "getty104",
"description": "This is a getty104's base tool set",
"version": "0.0.1"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "7da600323a5546b545ac5cd27b95500c50864a5dde0a1bb1ce884883886454a9"
},
{
"path": "agents/task-requirement-analyzer.md",
"sha256": "e6e3b7e4f345df3c7e8c055f5ce51606c630854a3525169fb40f32268ef1e1cb"
},
{
"path": "agents/github-issue-implementer.md",
"sha256": "1158a69a5353f7b35e18bac08ddd1b60838eb0dd87d9ba619b5dd0aa39da663a"
},
{
"path": "agents/general-purpose-assistant.md",
"sha256": "44186a20d4f8281b86a96584541d4fd63d330a0071f8a7b340b80d2ec6504629"
},
{
"path": "agents/review-comment-implementer.md",
"sha256": "96d8f7f628cdf8e08048f97e2002de3ef16c3d4188e9c34919a8a242b04e0118"
},
{
"path": "hooks/hooks.json",
"sha256": "1689a52e6a93de939ebf5220aedcd7f32a428639110f6b747ca1e73564ec8117"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "ce407d330fabe42d73ff134bd736113a667cd45bab4b3b4504a260906e10dfe3"
},
{
"path": "commands/exec-issue.md",
"sha256": "207147bd7427a0542ad5aff54a4ca15077d4ac09d6dbff1fb9a5de3f7c3f8c70"
},
{
"path": "commands/general-task.md",
"sha256": "a316726ce5538f6dffc4a81eeb1f560a19645c3d0ef489caee570454715da1e9"
},
{
"path": "commands/fix-review-point-loop.md",
"sha256": "a3b048f710823219a39fe6fee7375ee180ded74559573a481f51c0c1c9407809"
},
{
"path": "commands/create-worktree.md",
"sha256": "53ffdeae5b2399a5e56700ad5395a7b5e5612375451915507f57074e0d1dffa2"
},
{
"path": "commands/create-plan.md",
"sha256": "251a15545a9be260f94745a9f155cc949d8eea8ea31360e347af7308f4a71e16"
},
{
"path": "commands/fix-review-point.md",
"sha256": "01b25e6721fee0800ceddfda7b7c054ea6cd223a8c72bd1cc0e8ee80c8991598"
},
{
"path": "skills/read-unresolved-pr-comments/SKILL.md",
"sha256": "d28564224a9cc202e2862b5fee42a691a48d8f88c2567d1034e0eb51a12c8b55"
},
{
"path": "skills/read-unresolved-pr-comments/scripts/read-unresolved-pr-comments.sh",
"sha256": "0769c213c62ef3cfbbc0dfefc52191ca5d615ba92829af16017ee899a592c6ff"
},
{
"path": "skills/check-library/examples.md",
"sha256": "b42599061d7887adb9059405f136d284ca003a59f6af6227cbe6295cbf1e8211"
},
{
"path": "skills/check-library/SKILL.md",
"sha256": "fd68cd27c2de3d72a22f893ef76abc9ed78eb74383374dbe6ffae46b2ed311ad"
},
{
"path": "skills/create-git-worktree/SKILL.md",
"sha256": "467b85bbcbb6536b98c0a99a270c3be135b50aef84d8de4ca91f38289784194d"
},
{
"path": "skills/create-git-worktree/scripts/create-worktree.sh",
"sha256": "dd11843f4c84c95379b8e19a90efa6d292153c38c8f293fbaa51422fccd648a0"
},
{
"path": "skills/web-search/examples.md",
"sha256": "c6a6d9ca0a61c61b75ac9539edf29c88d861f154ba9204c566a8bca968950dc3"
},
{
"path": "skills/web-search/SKILL.md",
"sha256": "d8f62353586b705d7d5fd740838771c11213846ff0c1de60c7b572b8684b4eea"
},
{
"path": "skills/web-search/scripts/web-search.sh",
"sha256": "7f2fc4446d31a431e4f1e3718be6b6b5c7eb81da51424858c971b2b54acd4a3a"
},
{
"path": "skills/high-quality-commit/examples.md",
"sha256": "777c3889753c69db6fb6fff13111c58ab1b237f4dfa7c8a950830029298ac1f1"
},
{
"path": "skills/high-quality-commit/reference.md",
"sha256": "ce84a7256611880b856617be7c12e89187da6e911170cde2682214b269aa966b"
},
{
"path": "skills/high-quality-commit/SKILL.md",
"sha256": "1b212c48cd5b3ef29d704371dbaaedbc6e5eff94e0b4387c73f52eb52432de51"
},
{
"path": "skills/resolve-pr-comments/SKILL.md",
"sha256": "7cca85fad830ba2194f5572c43d21f0965ef98db8072ea2d48c79e2adddcca10"
},
{
"path": "skills/resolve-pr-comments/scripts/resolve-pr-comments.sh",
"sha256": "7f106cf278384a8a2a7b9c2533a98fb96f692f500e945aace5bc5f17cd26ae5c"
}
],
"dirSha256": "2f66a364d8034c42fbe3a979d751072b39f4ec4aed7495e31ac375ea6b5bf99a"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

View File

@@ -0,0 +1,75 @@
---
name: check-library
description: ライブラリの情報を確認するためのスキル。Next.js、shadcn、その他のライブラリについて、適切なMCPサーバーを使用して最新のドキュメントと使用方法を取得します。
---
# Check Library
このスキルは、ライブラリの情報を確認するために適切なMCPサーバーを選択して利用します。
## Instructions
ライブラリ名に応じて、以下の優先順位でMCPサーバーを使用してください
### 1. Next.js関連の場合
Next.jsに関する質問や実装の場合は、next-devtools MCPを使用します。
```
# 最初に初期化セッション開始時に1回のみ
mcp__plugin_getty104_next-devtools__init
# ドキュメント検索
mcp__plugin_getty104_next-devtools__nextjs_docs
action: "search"
query: "<検索キーワード>"
# ドキュメント取得(パスが分かっている場合)
mcp__plugin_getty104_next-devtools__nextjs_docs
action: "get"
path: "<ドキュメントパス>"
```
### 2. shadcn関連の場合
shadcn/uiに関する質問や実装の場合は、shadcn MCPを使用します。
```
# shadcn MCPツールを使用
# 利用可能なツールはListMcpResourcesToolで確認可能
```
### 3. その他のライブラリの場合
上記以外のライブラリについては、context7 MCPを使用します。
```
# ライブラリIDの解決
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "<ライブラリ名>"
# ドキュメント取得
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "<resolve-library-idで取得したID>"
topic: "<オプション: 特定のトピック>"
page: 1
```
## 使用例
### Next.jsのApp Routerについて調べる
1. `mcp__plugin_getty104_next-devtools__init` で初期化
2. `mcp__plugin_getty104_next-devtools__nextjs_docs` でApp Routerのドキュメントを検索
### shadcn/uiのButtonコンポーネントについて調べる
1. shadcn MCPのツールを使用してButtonコンポーネントの情報を取得
### React Queryの使い方を調べる
1. `mcp__plugin_getty104_context7__resolve-library-id` でReact QueryのライブラリIDを取得
2. `mcp__plugin_getty104_context7__get-library-docs` でドキュメントを取得
## 注意事項
- ライブラリ名が曖昧な場合は、ユーザーに確認してから適切なMCPを選択してください
- Next.jsとshadcnは専用のMCPがあるため、優先的に使用してください
- context7を使用する場合は、必ず `resolve-library-id` でライブラリIDを解決してから `get-library-docs` を使用してください

View File

@@ -0,0 +1,351 @@
# Check Library - Examples
このドキュメントでは、check-libraryスキルの具体的な使用例を示します。
## 例1: Next.jsのApp Routerについて調べる
### シナリオ
Next.js App Routerのレイアウト機能を使ってネストされたレイアウトを実装したい
### 手順
```bash
# 1. Next.js DevTools MCPの初期化
mcp__plugin_getty104_next-devtools__init
# 2. App Routerのレイアウト機能について検索
mcp__plugin_getty104_next-devtools__nextjs_docs
action: "search"
query: "nested layouts app router"
# 3. 詳細なドキュメントを取得(検索結果からパスを特定)
mcp__plugin_getty104_next-devtools__nextjs_docs
action: "get"
path: "app/building-your-application/routing/layouts-and-templates"
```
### 期待される結果
1. Next.jsの最新公式ドキュメントからレイアウト機能の情報を取得
2. ネストされたレイアウトの実装方法を理解
3. コード例と使用パターンを確認
## 例2: Next.jsのServer Actionsを実装
### シナリオ
フォーム送信にServer Actionsを使用したい
### 手順
```bash
# Next.js DevTools MCPでServer Actionsのドキュメントを検索
mcp__plugin_getty104_next-devtools__nextjs_docs
action: "search"
query: "server actions forms"
```
### 期待される結果
1. Server Actionsの基本的な使用方法を取得
2. フォームとの統合方法を理解
3. エラーハンドリングとバリデーションのパターンを確認
## 例3: shadcn/uiのButtonコンポーネントを追加
### シナリオ
プロジェクトにshadcn/uiのButtonコンポーネントを追加したい
### 手順
```bash
# shadcn MCPのツールを確認
ListMcpResourcesTool
server: "shadcn"
# Buttonコンポーネントの情報を取得
# (利用可能なツールに応じて適切なツールを使用)
```
### 期待される結果
1. Buttonコンポーネントのインストール方法を取得
2. コンポーネントのバリエーションと使用方法を理解
3. カスタマイズオプションを確認
## 例4: shadcn/uiのFormコンポーネントとReact Hook Formの統合
### シナリオ
shadcn/uiのFormコンポーネントとReact Hook Formを組み合わせて、フォームバリデーションを実装したい
### 手順
```bash
# shadcn MCPでFormコンポーネントの情報を取得
# (shadcn側のツールを使用)
# Context7 MCPでReact Hook Formのドキュメントを取得
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "react-hook-form"
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/react-hook-form/react-hook-form"
topic: "integration validation"
page: 1
```
### 期待される結果
1. shadcn/uiのFormコンポーネントの使用方法を理解
2. React Hook Formとの統合パターンを確認
3. バリデーションの実装方法を取得
## 例5: React Queryでデータフェッチングを実装
### シナリオ
React Query (TanStack Query) を使用してAPIからデータを取得したい
### 手順
```bash
# 1. ライブラリIDを解決
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "tanstack query"
# 2. useQueryフックのドキュメントを取得
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/tanstack/query"
topic: "useQuery"
page: 1
# 3. キャッシュ管理について追加で調べる
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/tanstack/query"
topic: "cache invalidation"
page: 1
```
### 期待される結果
1. React Queryの最新バージョンのドキュメントを取得
2. useQueryフックの使用方法を理解
3. キャッシュ管理のベストプラクティスを確認
## 例6: Zodでスキーマバリデーションを実装
### シナリオ
Zodを使用してフォームデータのバリデーションスキーマを定義したい
### 手順
```bash
# 1. ライブラリIDを解決
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "zod"
# 2. スキーマ定義のドキュメントを取得
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/colinhacks/zod"
topic: "schema validation"
page: 1
```
### 期待される結果
1. Zodの基本的なスキーマ定義方法を取得
2. バリデーションルールの記述方法を理解
3. TypeScript型推論の活用方法を確認
## 例7: Tailwind CSSのカスタム設定
### シナリオ
Tailwind CSSでカスタムカラーとブレークポイントを設定したい
### 手順
```bash
# 1. ライブラリIDを解決
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "tailwindcss"
# 2. 設定方法のドキュメントを取得
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/tailwindlabs/tailwindcss"
topic: "configuration customization"
page: 1
```
### 期待される結果
1. tailwind.config.jsの設定方法を取得
2. カスタムカラーの定義方法を理解
3. レスポンシブブレークポイントのカスタマイズ方法を確認
## 例8: Prismaでデータベーススキーマを定義
### シナリオ
Prismaを使用してリレーショナルデータベースのスキーマを定義したい
### 手順
```bash
# 1. ライブラリIDを解決
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "prisma"
# 2. スキーマ定義のドキュメントを取得
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/prisma/prisma"
topic: "schema relations"
page: 1
# 3. マイグレーションについて追加で調べる
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/prisma/prisma"
topic: "migrations"
page: 1
```
### 期待される結果
1. Prismaスキーマの基本的な記述方法を取得
2. リレーションの定義方法を理解
3. マイグレーション管理のベストプラクティスを確認
## 例9: 複数ライブラリを組み合わせた実装
### シナリオ
Next.js App Router + React Hook Form + Zod + Server Actionsでフォームを実装したい
### 手順
```bash
# 1. Next.js Server Actionsのドキュメントを確認
mcp__plugin_getty104_next-devtools__nextjs_docs
action: "search"
query: "server actions form validation"
# 2. React Hook Formの統合方法を確認
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "react-hook-form"
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/react-hook-form/react-hook-form"
topic: "server actions"
page: 1
# 3. Zodのスキーマ定義を確認
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "zod"
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/colinhacks/zod"
topic: "integration react-hook-form"
page: 1
```
### 期待される結果
1. 各ライブラリの最新ドキュメントを取得
2. ライブラリ間の統合パターンを理解
3. ベストプラクティスに基づいた実装方法を確認
## ライブラリ選択のポイント
### 1. Next.js関連の判定基準
以下のキーワードが含まれる場合は、Next.js DevTools MCPを使用
- Next.js、App Router、Pages Router
- Server Components、Server Actions
- Route Handlers、Middleware
- next/image、next/link、next/font
- generateStaticParams、generateMetadata
### 2. shadcn/ui関連の判定基準
以下のキーワードが含まれる場合は、shadcn MCPを使用
- shadcn/ui、shadcn
- Radix UIshadcnのベース
- Button、Card、Dialog、Form などのshadcnコンポーネント名
### 3. Context7使用の判定基準
上記以外の一般的なライブラリ:
- React Query (TanStack Query)
- Zod、Yup などのバリデーションライブラリ
- Tailwind CSS
- Prisma、Drizzle などのORM
- Axios、SWR などのデータフェッチングライブラリ
- その他のnpmパッケージ
## 効果的な使用方法
### トピック指定のコツ
Context7でドキュメントを取得する際は、具体的なトピックを指定すると効果的
```bash
# 悪い例:トピック指定なし
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/tanstack/query"
# 良い例:具体的なトピックを指定
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/tanstack/query"
topic: "useQuery mutations error handling"
page: 1
```
### ページネーション活用
情報が不足している場合は、pageパラメータを変更して追加情報を取得
```bash
# 1ページ目で基本情報を取得
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/prisma/prisma"
topic: "schema"
page: 1
# 2ページ目で詳細情報を取得
mcp__plugin_getty104_context7__get-library-docs
context7CompatibleLibraryID: "/prisma/prisma"
topic: "schema"
page: 2
```
### ライブラリ名解決のコツ
`resolve-library-id`では、正式なライブラリ名だけでなく、一般的な呼び方でも検索可能:
```bash
# どちらでも動作
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "react-hook-form"
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "react hook form"
mcp__plugin_getty104_context7__resolve-library-id
libraryName: "rhf"
```
## まとめ
check-libraryスキルを効果的に使用するためのポイント
1. **ライブラリの種類を正しく判定**: Next.js、shadcn、その他を適切に区別
2. **具体的なトピックを指定**: 必要な情報を効率的に取得
3. **複数のMCPを組み合わせる**: 統合パターンを理解するために複数のライブラリを調査
4. **最新情報を確認**: 各MCPは最新のドキュメントを提供
5. **段階的に深掘り**: まず概要を取得し、必要に応じて詳細を調査
これらの原則に従うことで、ライブラリの正しい使用方法を迅速に理解し、品質の高い実装が可能になります。

View File

@@ -0,0 +1,15 @@
---
name: create-git-worktree
description: git worktree を利用した分離作業環境を自動構築します。デフォルトブランチから最新コードを取得し、.git-worktrees/ ディレクトリに新規worktreeを作成、.env・Serena memories・npm依存関係を自動セットアップします。ブランチ名の '/' は自動的に '-' に変換されます。既存worktreeは再利用されます。
---
# Create Git Worktree and Setup Environment
## Instructions
以下のコマンドを実行して、git worktreeを作成し、環境のセットアップを行います。
引数にはgit worktree化するブランチ名を指定してください。
```
bash ${CLAUDE_PLUGIN_ROOT}/scripts/create-worktree.sh [ブランチ名]
```

View File

@@ -0,0 +1,72 @@
#!/bin/bash
set -e
if [ -z "$1" ]; then
echo "Usage: $0 <branch-name>"
echo "Example: $0 feature/new-feature"
exit 1
fi
BRANCH_NAME="$1"
WORKTREE_NAME=$(echo "$BRANCH_NAME" | tr '/' '-')
WORKTREE_PATH=".git-worktrees/$WORKTREE_NAME"
REPO_ROOT=$(git rev-parse --show-toplevel)
echo "Creating worktree for branch: $BRANCH_NAME"
echo "Worktree path: $WORKTREE_PATH"
cd "$REPO_ROOT"
BASE_BRANCH=$(git remote show origin | grep 'HEAD branch' | awk '{print $NF}')
git checkout "$BASE_BRANCH"
git pull
mkdir -p .git-worktrees
if [ -d "$WORKTREE_PATH" ]; then
echo ""
echo "✓ Worktree already exists at: $WORKTREE_PATH"
echo ""
echo "Next steps:"
echo "1. cd $WORKTREE_PATH"
echo "2. Continue working on your task"
echo ""
exit 0
fi
if git show-ref --verify --quiet "refs/heads/$BRANCH_NAME"; then
git worktree add "$WORKTREE_PATH" "$BRANCH_NAME"
else
git worktree add -b "$BRANCH_NAME" "$WORKTREE_PATH"
fi
if [ -f .env ]; then
cp .env "$WORKTREE_PATH/.env"
echo "Copied .env file to worktree"
fi
cd "$WORKTREE_PATH"
if [ -d "$REPO_ROOT/.serena" ]; then
mkdir -p .serena
if [ -d "$REPO_ROOT/.serena/memories" ]; then
cp -r "$REPO_ROOT/.serena/memories" .serena/memories
echo "Copied Serena memories to worktree"
fi
fi
if [ -f package.json ]; then
echo "Installing npm dependencies..."
npm install
fi
echo ""
echo "✓ Worktree created successfully!"
echo ""
echo "Next steps:"
echo "1. cd $WORKTREE_PATH"
echo "2. Activate Serena and complete onboarding if needed"
echo "3. Start working on your task"
echo ""
echo "When done, don't forget to run 'docker compose down' if using Docker"

View File

@@ -0,0 +1,147 @@
---
name: high-quality-commit
description: コード変更を適切なgitコミット戦略でgit commitします。基本的には既存のgitコミットへのsquash戦略を採用し、必要に応じてブランチ全体のgitコミット履歴を再構成します。実装完了時やユーザーがgit commitを依頼した時に使用します。
---
# High Quality Commit
このスキルは、コード変更を高品質なgitコミットとして記録するための包括的なガイダンスを提供します。
## Instructions
### ステップ1: ブランチとgitコミット履歴の確認
以下のコマンドで現在の状態を確認:
```bash
git status
git log --oneline --graph origin/main..HEAD
```
確認事項:
- 現在のブランチ名
- mainブランチから何gitコミット進んでいるか
- 各gitコミットの内容と粒度
### ステップ2: gitコミット戦略の判断
以下の基準でgitコミット戦略を選択
#### 戦略A: Squash基本戦略
以下の条件を満たす場合、既存のgitコミットにsquashします
- ブランチに既にgitコミットが存在する
- 変更内容が既存のgitコミットと同じテーマ・機能に関連している
- gitコミットを分ける合理的な理由がない
**実行方法:**
```bash
git add -A
git commit --amend
```
gitコミットメッセージを適切に更新してください。
#### 戦略B: 新規gitコミット
以下の場合は新規gitコミットを作成
- ブランチに初めてのgitコミット
- 既存のgitコミットとは異なる独立した変更
- gitコミットを分けることで履歴がより理解しやすくなる
**実行方法:**
```bash
git add -A
git commit
```
#### 戦略C: Interactive Rebasegitコミット再構成
以下の場合はブランチ全体のgitコミットを再構成
- 複数の小さなgitコミットを論理的なまとまりに整理したい
- gitコミットの順序を変更したい
- 不要なgitコミットを削除したい
- gitコミット履歴を意味のある単位に再編成したい
**実行方法:**
```bash
git rebase -i origin/main
```
エディタで以下の操作を実行:
- `pick`: gitコミットをそのまま維持
- `squash`または`s`: 前のgitコミットと統合
- `reword`または`r`: gitコミットメッセージを変更
- 行の順序を変更してgitコミット順を変更
### ステップ3: gitコミットメッセージのガイドライン
gitコミットメッセージは以下の形式で記述
```
<type>: <subject>
<body>
<footer>
```
**Type:**
- `feat`: 新機能
- `fix`: バグ修正
- `refactor`: リファクタリング
- `test`: テスト追加・修正
- `docs`: ドキュメント変更
- `chore`: ビルドプロセスやツールの変更
**Subject:**
- 50文字以内
- 命令形で記述(例: "add"ではなく"Add"
- 末尾にピリオドを付けない
**Bodyオプション:**
- 変更の理由と背景を説明
- 何を変更したかではなく、なぜ変更したかを記述
- 72文字で折り返す
**Footerオプション:**
- Issue番号への参照例: `Closes #123`
- Breaking changesの記述
### ステップ4: git commit後の確認
git commit後、以下を確認
```bash
git log -1 --stat
git status
```
- gitコミットが正しく作成されたか
- 意図したファイルがすべて含まれているか
- gitコミットメッセージが適切か
## 重要な注意事項
1. **mainブランチでは実行しない**: mainブランチで直接git commitしないでください
2. **コメントは残さない**: コード内の説明コメントは削除してください
3. **原子的なgitコミット**: 各gitコミットは独立して意味を持つようにしてください
4. **一貫性**: プロジェクトの既存のgitコミットスタイルに従ってください
## 戦略選択のフローチャート
```
ブランチにgitコミットがある
├─ No → 新規gitコミット作成
└─ Yes → 変更は既存のgitコミットと同じテーマ
├─ Yes → Squashgit commit --amend
└─ No → gitコミットを分ける合理性がある
├─ Yes → 新規gitコミット作成
└─ 履歴を整理したい → Interactive Rebase
```

View File

@@ -0,0 +1,350 @@
# High Quality Commit - Examples
このドキュメントでは、実際の開発シナリオでの具体的な使用例を示します。
## 例1: 初回実装でのgitコミット
### シナリオ
新機能「ユーザープロフィール編集」を実装し、初めてgit commitする
### 手順
```bash
# 1. ブランチ状況確認
git status
# On branch feature/user-profile-edit
# Changes not staged for commit:
# modified: src/components/UserProfile.tsx
# modified: src/api/user.ts
# new file: src/components/ProfileEditForm.tsx
git log --oneline --graph origin/main..HEAD
# (no commits yet on this branch)
# 2. 戦略判断: ブランチに初めてのgitコミット → 新規gitコミット
# 3. git commit実行
git add -A
git commit
```
### gitコミットメッセージ
```
feat: add user profile editing feature
Implement profile editing functionality:
- Add ProfileEditForm component with validation
- Add PUT /api/users/:id endpoint
- Integrate form with existing UserProfile component
Users can now update their display name, email, and bio.
Closes #234
```
## 例2: レビュー指摘への対応Squash
### シナリオ
PR作成後、レビューで「バリデーションロジックを改善してください」という指摘を受けた
### 手順
```bash
# 1. 現在のコミット確認
git log --oneline --graph origin/main..HEAD
# * a1b2c3d feat: add user profile editing feature
# 2. 指摘箇所を修正
# src/components/ProfileEditForm.tsx を編集...
# 3. 戦略判断: 既存コミットと同じテーマ → Squash
# 4. 既存コミットに統合
git add -A
git commit --amend
```
### 更新されたコミットメッセージ
```
feat: add user profile editing feature
Implement profile editing functionality:
- Add ProfileEditForm component with enhanced validation
- Add PUT /api/users/:id endpoint
- Integrate form with existing UserProfile component
Validation improvements:
- Email format validation with regex
- Display name length constraints (3-50 chars)
- Real-time validation feedback
Users can now update their display name, email, and bio.
Closes #234
```
```bash
# 6. 強制pushPRを更新
git push --force-with-lease
```
## 例3: 独立した機能追加(新規コミット)
### シナリオ
ユーザープロフィール編集機能の実装後、別途「プロフィール画像アップロード」機能を追加することになった
### 手順
```bash
# 1. 現在のコミット確認
git log --oneline --graph origin/main..HEAD
# * a1b2c3d feat: add user profile editing feature
# 2. プロフィール画像アップロード機能を実装
# ...
# 3. 戦略判断: 既存コミットとは独立した機能 → 新規コミット
# 4. 新規コミット作成
git add -A
git commit
```
### gitコミットメッセージ
```
feat: add profile picture upload
Implement profile picture upload functionality:
- Add image upload component with drag-and-drop
- Add POST /api/users/:id/avatar endpoint
- Add image cropping and preview
- Store images in cloud storage
Supports JPEG, PNG, and WebP formats up to 5MB.
Closes #235
```
```bash
# 5. 結果確認
git log --oneline --graph origin/main..HEAD
# * e4f5g6h feat: add profile picture upload
# * a1b2c3d feat: add user profile editing feature
```
## 例4: WIPコミットの整理Interactive Rebase
### シナリオ
開発中に多数の小さなコミットを作成してしまった。PR作成前に整理したい。
### 現状のコミット履歴
```bash
git log --oneline --graph origin/main..HEAD
# * h7i8j9k WIP: fix typo
# * e4f5g6h WIP: add validation
# * b2c3d4e feat: add profile form
# * y9z0a1b WIP: experiment with layout
# * v6w7x8y feat: add user model
# * s3t4u5v fix: import statement
```
### 手順
```bash
# 1. Interactive rebaseを開始
git rebase -i origin/main
# 2. エディタが開く
```
### エディタでの編集
変更前:
```
pick v6w7x8y feat: add user model
pick s3t4u5v fix: import statement
pick y9z0a1b WIP: experiment with layout
pick b2c3d4e feat: add profile form
pick e4f5g6h WIP: add validation
pick h7i8j9k WIP: fix typo
```
変更後:
```
pick v6w7x8y feat: add user model
squash s3t4u5v fix: import statement
drop y9z0a1b WIP: experiment with layout
pick b2c3d4e feat: add profile form
squash e4f5g6h WIP: add validation
squash h7i8j9k WIP: fix typo
```
### 保存後の編集
2つのコミットメッセージを編集
**1つ目のコミット**
```
feat: add user profile model
Define user profile data structure with TypeScript:
- User interface with profile fields
- Profile validation schema
- Type-safe profile operations
Includes display name, email, bio, and avatar URL.
```
**2つ目のコミット**
```
feat: add profile editing form
Implement profile editing UI component:
- Form layout with Material-UI
- Real-time field validation
- Success/error feedback
Users can update their profile information with immediate validation.
```
### 結果確認
```bash
git log --oneline --graph origin/main..HEAD
# * m1n2o3p feat: add profile editing form
# * j4k5l6m feat: add user profile model
# クリーンな履歴に整理された!
```
## 例5: 複数機能の段階的実装
### シナリオ
大きな機能「認証システム」を、Model → API → UIの順で段階的に実装
### 手順
#### ステップ1: モデル実装
```bash
# 実装...
git add src/models/
git commit -m "feat: add authentication model
Define authentication data structures:
- User model with credentials
- JWT token interface
- Session management types
Provides type-safe authentication operations."
git push
```
#### ステップ2: API実装
```bash
# 実装...
git add src/api/auth.ts
git commit -m "feat: add authentication API endpoints
Implement authentication REST API:
- POST /api/auth/login - User login
- POST /api/auth/logout - User logout
- POST /api/auth/refresh - Token refresh
- GET /api/auth/me - Get current user
Uses JWT for secure token-based authentication."
git push
```
#### ステップ3: UI実装
```bash
# 実装...
git add src/components/auth/
git commit -m "feat: add authentication UI components
Implement authentication user interface:
- LoginForm component with validation
- Protected route wrapper
- Session persistence
- Auto token refresh
Provides complete authentication UX."
git push
```
### 最終的な履歴
```bash
git log --oneline --graph origin/main..HEAD
# * q5r6s7t feat: add authentication UI components
# * n2o3p4q feat: add authentication API endpoints
# * k8l9m0n feat: add authentication model
# 各コミットが独立してレビュー可能
# 各コミットが単独でビルド・テスト可能
```
## 例6: バグ修正とテスト追加
### シナリオ
バグを発見し、修正とテストを同時に実施
### 手順
```bash
# 1. 現在の作業を確認
git status
# On branch fix/validation-bug
# 2. バグ修正とテスト追加
# src/utils/validation.ts を修正
# src/utils/validation.test.ts を追加
# 3. コミット
git add -A
git commit
```
### gitコミットメッセージ
```
fix: correct email validation regex
Fix email validation to properly handle plus signs (+) in addresses.
Previously, emails like "user+tag@example.com" were incorrectly rejected.
Changes:
- Update regex pattern to include + character
- Add comprehensive test cases for edge cases
Closes #456
```
## まとめ
これらの例から学べる重要なポイント:
1. **適切な戦略選択**: シナリオに応じてSquash/新規gitコミット/Rebaseを使い分け
2. **明確なメッセージ**: 「なぜ」その変更が必要だったのかを記述
3. **論理的な単位**: 各gitコミットが独立して理解できる粒度
4. **継続的な改善**: レビューフィードバックを反映して品質向上
これらの原則に従うことで、チーム全体の生産性が向上します。

View File

@@ -0,0 +1,253 @@
# High Quality Commit - Reference Guide
このドキュメントは、高品質なgitコミットを作成するための詳細なガイダンスとベストプラクティスを提供します。
## gitコミット戦略の詳細
### Squash戦略デフォルト
**使用タイミング:**
- 継続的な開発中で、機能追加やバグ修正を繰り返している
- レビュー指摘への対応や微調整を行っている
- 同じ機能に関連する複数の変更を一つにまとめたい
**メリット:**
- ブランチのgitコミット履歴がクリーンになる
- レビュー時に一つの論理的な変更として見やすい
- PRマージ時に整理されたgitコミット履歴が残る
**実行例:**
```bash
# 変更をステージング
git add -A
# 直前のコミットに統合(メッセージを編集)
git commit --amend
# または、メッセージを変更せずに統合
git commit --amend --no-edit
```
**注意点:**
- 既にpushしたgitコミットをamendする場合は、force pushが必要
- チーム開発では他の人がそのgitコミットをベースにしていないか確認
### 新規gitコミット戦略
**使用タイミング:**
- 明確に異なる機能や修正を追加する
- gitコミットを分けることで履歴の理解が容易になる
- 各gitコミットが独立してビルド・テスト可能
**メリット:**
- 変更のgitコミット履歴が詳細に残る
- git bisectなどでの問題追跡が容易
- 特定の変更だけをrevertできる
**実行例:**
```bash
# 変更をステージング
git add -A
# 新規コミット作成
git commit -m "feat: add user authentication
Implement JWT-based authentication:
- Add login endpoint
- Add token validation middleware
- Add user session management
Closes #123"
```
### Interactive Rebase戦略
**使用タイミング:**
- PR作成前にgitコミット履歴を整理したい
- 複数の小さなgitコミットを論理的にまとめたい
- gitコミットの順序を変更したい
- 不要なgitコミットWIP、fixupなどを削除したい
**メリット:**
- クリーンで意味のあるgitコミット履歴が作成できる
- レビュアーが理解しやすい
- mainブランチのgitコミット履歴が整理される
**実行例:**
```bash
# mainブランチとの差分で対話的にrebase
git rebase -i origin/main
# または、最新のN個のコミットをrebase
git rebase -i HEAD~3
```
**エディタでの操作:**
```
pick abc1234 feat: add user model
pick def5678 fix: typo in user model
pick ghi9012 feat: add user controller
pick jkl3456 fix: validation logic
# ↓ 以下のように編集
pick abc1234 feat: add user model
squash def5678 fix: typo in user model
pick ghi9012 feat: add user controller
squash jkl3456 fix: validation logic
```
結果2つの論理的なコミットに統合される
## gitコミットメッセージのベストプラクティス
### 良いgitコミットメッセージの例
```
feat: add user profile editing feature
Allow users to update their profile information including:
- Display name
- Email address
- Profile picture
- Bio
Implemented with form validation and real-time preview.
Closes #456
```
### 避けるべきgitコミットメッセージ
```
# 悪い例1: 不明確
update files
# 悪い例2: 詳細すぎる実装の説明
Changed UserController.ts line 45 to use async/await instead of promises
# 悪い例3: 複数の無関係な変更
Fix bug and add feature and update docs
```
### Type選択のガイド
- **feat**: ユーザーに見える新機能
- **fix**: ユーザーに影響するバグ修正
- **refactor**: 動作を変えないコードの改善
- **perf**: パフォーマンス改善
- **test**: テストの追加・修正
- **docs**: ドキュメントのみの変更
- **style**: コードフォーマット、セミコロンなど
- **chore**: ビルド、依存関係の更新など
## よくあるシナリオと対応
### シナリオ1: レビュー指摘への対応
**状況:** PRにレビューコメントがあり、修正が必要
**推奨戦略:** Squash
```bash
# 修正を実施
# ...
# 既存のコミットに統合
git add -A
git commit --amend
# 強制pushPRを更新
git push --force-with-lease
```
### シナリオ2: 大きな機能の段階的実装
**状況:** 大きな機能を複数のステップで実装している
**推奨戦略:** 新規コミット(各段階ごと)
```bash
# ステップ1: モデル作成
git add src/models/
git commit -m "feat: add user authentication model"
# ステップ2: API実装
git add src/api/
git commit -m "feat: add authentication API endpoints"
# ステップ3: UI実装
git add src/components/
git commit -m "feat: add login UI components"
```
### シナリオ3: WIPコミットの整理
**状況:** 開発中に多数のWIPコミットを作成してしまった
**推奨戦略:** Interactive Rebase
```bash
# WIPコミットを確認
git log --oneline
# Interactive rebaseで整理
git rebase -i origin/main
# エディタで不要なコミットをsquash/fixupに変更
# 意味のあるコミットだけを残す
```
## トラブルシューティング
### 問題: amendしたコミットがpushできない
**原因:** リモートの履歴と異なる
**解決策:**
```bash
# 安全な強制push
git push --force-with-lease
```
### 問題: rebase中にコンフリクト
**解決策:**
```bash
# コンフリクトを解決
# ファイルを編集...
# 解決後、rebaseを続行
git add .
git rebase --continue
# または中止
git rebase --abort
```
### 問題: 誤ってamendしてしまった
**解決策:**
```bash
# reflogで以前の状態を確認
git reflog
# 以前のコミットに戻る
git reset --hard HEAD@{1}
```
## まとめ
高品質なgitコミットのための2つの原則
1. **適切な戦略を選択**: Squash基本、新規gitコミット独立した変更、Rebasegitコミット履歴整理
2. **明確なメッセージ**: なぜその変更が必要だったのかを記述
これらを守ることで、チーム全体の開発効率が向上し、将来のメンテナンスが容易になります。

View File

@@ -0,0 +1,13 @@
---
name: read-unresolved-pr-comments
description: GitHub PRから未対応のコメントを取得します。GraphQL APIで (1) コード特定行への未解決Review threadsResolve可能と (2) コードブロックを含むIssue comments会話タブ、Resolve不可の両方を取得し、JSON形式で出力します。PR情報番号・タイトル・URL・状態・作成者・レビュアーも含まれます。
---
# Read Unresolved PR Comments
## Instructions
以下のコマンドを実行して、未解決のプルリクエストレビューコメントを取得します。
```
bash ${CLAUDE_PLUGIN_ROOT}/scripts/read-unresolved-pr-comments.sh
```

View File

@@ -0,0 +1,157 @@
OWNER_REPO="$(gh repo view --json nameWithOwner --jq '.nameWithOwner')"
OWNER="$(echo $OWNER_REPO | cut -d'/' -f1)"
REPO="$(echo $OWNER_REPO | cut -d'/' -f2)"
PR_NUMBER="$(gh pr view --json number --jq '.number')"
fetch_all_review_threads() {
local cursor=""
local has_next_page=true
local temp_dir=$(mktemp -d)
local page_num=0
while [ "$has_next_page" = "true" ]; do
if [ -z "$cursor" ]; then
gh api graphql -f query="
query {
repository(owner: \"${OWNER}\", name: \"${REPO}\") {
pullRequest(number: ${PR_NUMBER}) {
number
title
url
state
author {
login
}
reviewRequests(first: 100) {
nodes {
requestedReviewer {
... on User {
login
}
}
}
}
reviewThreads(first: 100) {
pageInfo {
hasNextPage
endCursor
}
edges {
node {
id
isResolved
isOutdated
path
line
comments(last: 100) {
nodes {
author {
login
}
body
url
createdAt
}
}
}
}
}
}
}
}" > "${temp_dir}/page_${page_num}.json"
else
gh api graphql -f query="
query(\$cursor: String) {
repository(owner: \"${OWNER}\", name: \"${REPO}\") {
pullRequest(number: ${PR_NUMBER}) {
number
title
url
state
author {
login
}
reviewRequests(first: 100) {
nodes {
requestedReviewer {
... on User {
login
}
}
}
}
reviewThreads(first: 100, after: \$cursor) {
pageInfo {
hasNextPage
endCursor
}
edges {
node {
id
isResolved
isOutdated
path
line
comments(last: 100) {
nodes {
author {
login
}
body
url
createdAt
}
}
}
}
}
}
}
}" -f cursor="$cursor" > "${temp_dir}/page_${page_num}.json"
fi
has_next_page=$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage' "${temp_dir}/page_${page_num}.json")
cursor=$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.endCursor' "${temp_dir}/page_${page_num}.json")
if [ "$cursor" = "null" ]; then
cursor=""
fi
page_num=$((page_num + 1))
done
jq -s '
.[0].data.repository.pullRequest as $first_pr |
{
pr_number: $first_pr.number,
title: $first_pr.title,
url: $first_pr.url,
state: $first_pr.state,
author: $first_pr.author.login,
requested_reviewers: [$first_pr.reviewRequests.nodes[].requestedReviewer.login],
unresolved_threads: [
.[].data.repository.pullRequest.reviewThreads.edges[] |
select(.node.isResolved == false) |
{
thread_id: .node.id,
path: .node.path,
line: .node.line,
is_outdated: .node.isOutdated,
comments: [
.node.comments.nodes[] |
{
author: .author.login,
body: .body,
url: .url,
created_at: .createdAt
}
]
}
]
}
' "${temp_dir}"/page_*.json
rm -rf "$temp_dir"
}
fetch_all_review_threads

View File

@@ -0,0 +1,14 @@
---
name: resolve-pr-comments
description: GitHub PRの未解決Review threadsを一括Resolveします。GraphQL APIで未解決のReview threadsコード特定行へのコメントを取得し、resolveReviewThread mutationで全て自動的にResolveします。Issue comments会話タブは元々Resolve機能がないため対象外です。各スレッドのResolve結果を表示します。
---
# Resolve PR Comments
## Instructions
以下のコマンドでResolveしていないレビューコメントをResolveします。
```
bash ${CLAUDE_PLUGIN_ROOT}/scripts/resolve-pr-comments.sh
```

View File

@@ -0,0 +1,174 @@
OWNER_REPO="$(gh repo view --json nameWithOwner --jq '.nameWithOwner')"
OWNER="$(echo $OWNER_REPO | cut -d'/' -f1)"
REPO="$(echo $OWNER_REPO | cut -d'/' -f2)"
PR_NUMBER="$(gh pr view --json number --jq '.number')"
fetch_all_review_threads() {
local cursor=""
local has_next_page=true
local temp_dir=$(mktemp -d)
local page_num=0
while [ "$has_next_page" = "true" ]; do
if [ -z "$cursor" ]; then
gh api graphql -f query="
query {
repository(owner: \"${OWNER}\", name: \"${REPO}\") {
pullRequest(number: ${PR_NUMBER}) {
number
title
url
state
author {
login
}
reviewRequests(first: 100) {
nodes {
requestedReviewer {
... on User {
login
}
}
}
}
reviewThreads(first: 100) {
pageInfo {
hasNextPage
endCursor
}
edges {
node {
id
isResolved
isOutdated
path
line
comments(last: 100) {
nodes {
author {
login
}
body
url
createdAt
}
}
}
}
}
}
}
}" > "${temp_dir}/page_${page_num}.json"
else
gh api graphql -f query="
query(\$cursor: String) {
repository(owner: \"${OWNER}\", name: \"${REPO}\") {
pullRequest(number: ${PR_NUMBER}) {
number
title
url
state
author {
login
}
reviewRequests(first: 100) {
nodes {
requestedReviewer {
... on User {
login
}
}
}
}
reviewThreads(first: 100, after: \$cursor) {
pageInfo {
hasNextPage
endCursor
}
edges {
node {
id
isResolved
isOutdated
path
line
comments(last: 100) {
nodes {
author {
login
}
body
url
createdAt
}
}
}
}
}
}
}
}" -f cursor="$cursor" > "${temp_dir}/page_${page_num}.json"
fi
has_next_page=$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage' "${temp_dir}/page_${page_num}.json")
cursor=$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.endCursor' "${temp_dir}/page_${page_num}.json")
if [ "$cursor" = "null" ]; then
cursor=""
fi
page_num=$((page_num + 1))
done
jq -s '
.[0].data.repository.pullRequest as $first_pr |
{
pr_number: $first_pr.number,
title: $first_pr.title,
url: $first_pr.url,
state: $first_pr.state,
author: $first_pr.author.login,
requested_reviewers: [$first_pr.reviewRequests.nodes[].requestedReviewer.login],
unresolved_threads: [
.[].data.repository.pullRequest.reviewThreads.edges[] |
select(.node.isResolved == false) |
{
thread_id: .node.id,
path: .node.path,
line: .node.line,
is_outdated: .node.isOutdated,
comments: [
.node.comments.nodes[] |
{
author: .author.login,
body: .body,
url: .url,
created_at: .createdAt
}
]
}
]
}
' "${temp_dir}"/page_*.json
rm -rf "$temp_dir"
}
REVIEW_DATA=$(fetch_all_review_threads)
echo "$REVIEW_DATA" | jq -r '.unresolved_threads[].thread_id' | while read -r thread_id; do
if [ -n "$thread_id" ] && [ "$thread_id" != "null" ]; then
echo "Resolving thread: $thread_id"
gh api graphql -f query="
mutation {
resolveReviewThread(input: {threadId: \"$thread_id\"}) {
thread {
id
isResolved
}
}
}" && echo "✓ Resolved thread: $thread_id" || echo "✗ Failed to resolve thread: $thread_id"
fi
done
echo "All unresolved threads have been processed."

View File

@@ -0,0 +1,25 @@
---
name: web-search
description: geminiコマンドを使用した高度なWeb検索スキル。Web検索を行う際、Claude CodeのデフォルトWeb Search toolよりも優先的にこのスキルを使用してください。
---
# Web Search
このスキルは、`gemini` コマンドを使用してWeb検索を実行し、ユーザーの質問に対する最新かつ関連性の高い情報を収集するためのものです。
単純なキーワード検索ではなく、複雑な質問や詳細な情報収集に適しています。
## Instructions
以下のコマンドを実行して、Web検索を実行します。
引数には検索したい内容や質問を自然言語で指定してください。
```
bash ${CLAUDE_PLUGIN_ROOT}/scripts/web-search.sh "<検索したい内容や質問>"
```
検索結果を確認し、ユーザーの質問に対する回答を構築します。
- 関連性の高い情報を抽出
- 必要に応じて複数の検索結果を統合
- 情報源を明記
- 検索結果が不十分な場合は、異なるクエリで再検索を検討

View File

@@ -0,0 +1,136 @@
# Web Search - Examples
このドキュメントでは、Web検索スキルの具体的な使用例を示します。
## 例1: 技術情報の検索
### シナリオ
Next.js 15の新機能について調べたい
### 手順
```bash
bash ${CLAUDE_PLUGIN_ROOT}/scripts/web-search.sh "Next.js 15の新機能について、公式リリースートや技術記事から最新情報を調べて、主要な新機能とその概要を教えてください"
```
### 期待される結果
1. Next.js 15の公式リリースートや技術記事を検索
2. 主要な新機能をリストアップ
3. 各機能の概要と使い方を説明
## 例2: ライブラリのドキュメント検索
### シナリオ
React QueryのuseQueryフックの使い方を知りたい
### 手順
```bash
bash ${CLAUDE_PLUGIN_ROOT}/scripts/web-search.sh "React QueryのuseQueryフックの基本的な使い方を、公式ドキュメントから調べて、コード例を含めて説明してください"
```
### 期待される結果
1. React Queryの公式ドキュメントを検索
2. useQueryの基本的な使用方法を抽出
3. コード例を含めて説明
## 例3: エラーメッセージの解決方法検索
### シナリオ
TypeScriptで型エラーが発生した時の対処法を調べたい
### 手順
```bash
bash ${CLAUDE_PLUGIN_ROOT}/scripts/web-search.sh "TypeScriptで 'Type string is not assignable to type number' というエラーが発生する原因と、具体的な解決方法を調べてください"
```
### 期待される結果
1. 同様のエラーに関するStack OverflowやGitHub Issuesを検索
2. 一般的な原因を説明
3. 具体的な解決方法を提示
## 例4: 最新ニュースの検索
### シナリオ
Claude AIの最新アップデート情報を知りたい
### 手順
```bash
bash ${CLAUDE_PLUGIN_ROOT}/scripts/web-search.sh "Claude AIの2025年の最新アップデート情報を調べて、リリース日や主要な変更点をまとめてください"
```
### 期待される結果
1. Anthropicの公式発表やテックニュースを検索
2. 最新のアップデート内容をまとめる
3. リリース日や主要な変更点を説明
## 例5: ベストプラクティスの検索
### シナリオ
Reactのパフォーマンス最適化方法を調べたい
### 手順
```bash
bash ${CLAUDE_PLUGIN_ROOT}/scripts/web-search.sh "Reactアプリケーションのパフォーマンスを最適化するベストプラクティスを調べて、主要なテクニックとその適用方法を説明してください"
```
### 期待される結果
1. Reactの公式ドキュメントや技術記事を検索
2. 主要な最適化テクニックをリストアップ
3. 各テクニックの適用方法を説明
## 例6: 比較情報の検索
### シナリオ
ViteとWebpackの違いを理解したい
### 手順
```bash
bash ${CLAUDE_PLUGIN_ROOT}/scripts/web-search.sh "ViteとWebpackを比較して、主要な違い、それぞれのメリット・デメリット、使い分けの推奨を調べてください"
```
### 期待される結果
1. 両者の比較記事やベンチマークを検索
2. 主要な違いを表形式でまとめる
3. それぞれの利点と欠点を説明
4. 使い分けの推奨を提示
## 検索クエリのポイント
### 効果的な検索クエリの作り方
1. **明確な質問形式**
- 「〜について教えてください」「〜を調べてください」など、明確な依頼として記述
- 知りたい内容を具体的に指定
2. **情報源の指定**
- 「公式ドキュメントから」「リリースノートから」など、参照してほしい情報源を明記
- より正確な情報が必要な場合に有効
3. **回答形式の指定**
- 「コード例を含めて」「表形式で」など、望む回答の形式を指定
- 「主要な〜をリストアップ」など、まとめ方を指示
4. **時期や条件の指定**
- 「2025年の」「最新の」など、情報の鮮度を指定
- 「初心者向けに」「詳しく」など、詳細度を調整
5. **比較や分析の指示**
- 「比較して」「違いを」など、分析の観点を明確に
- 「メリット・デメリット」「使い分け」など、求める分析内容を指定

View File

@@ -0,0 +1,24 @@
#!/bin/bash
set -e
if [ -z "$1" ]; then
echo "Usage: $0 <search-query>"
echo "Example: $0 \"Next.js 15の新機能について教えて\""
exit 1
fi
SEARCH_QUERY="$1"
gemini -p "
## タスク
「依頼内容」を達成するために、ウェブ検索を行い、できるだけ詳細に回答してください。
## 依頼内容
${SEARCH_QUERY}
## 結果のフォーマット
- 回答はMarkdown形式で記述すること
- 検索結果はファイルなどに書き出さず、レスポンスとして返すこと
- 回答には参考にしたURLを全て一覧として含めること
" --yolo --output-format json