zhongwei/gh-getty104-claude-code-marketplace-getty104
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
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
Download Patch File Download Diff File Expand all files Collapse all files

75
skills/check-library/SKILL.md Normal file
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` を使用してください

351
skills/check-library/examples.md Normal file
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 UI（shadcnのベース）
- 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. **段階的に深掘り**: まず概要を取得し、必要に応じて詳細を調査
これらの原則に従うことで、ライブラリの正しい使用方法を迅速に理解し、品質の高い実装が可能になります。

15
skills/create-git-worktree/SKILL.md Normal file
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 [ブランチ名]
```

72
skills/create-git-worktree/scripts/create-worktree.sh Executable file
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"

147
skills/high-quality-commit/SKILL.md Normal file
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 Rebase（gitコミット再構成）
以下の場合はブランチ全体の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 → Squash（git commit --amend）
└─ No → gitコミットを分ける合理性がある？
├─ Yes → 新規gitコミット作成
└─ 履歴を整理したい → Interactive Rebase
```

350
skills/high-quality-commit/examples.md Normal file
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. 強制push（PRを更新）
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. **継続的な改善**: レビューフィードバックを反映して品質向上
これらの原則に従うことで、チーム全体の生産性が向上します。

253
skills/high-quality-commit/reference.md Normal file
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
# 強制push（PRを更新）
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コミット（独立した変更）、Rebase（gitコミット履歴整理）
2. **明確なメッセージ**: なぜその変更が必要だったのかを記述
これらを守ることで、チーム全体の開発効率が向上し、将来のメンテナンスが容易になります。

13
skills/read-unresolved-pr-comments/SKILL.md Normal file
View File

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

157
skills/read-unresolved-pr-comments/scripts/read-unresolved-pr-comments.sh Normal file
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

14
skills/resolve-pr-comments/SKILL.md Normal file
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
```

174
skills/resolve-pr-comments/scripts/resolve-pr-comments.sh Normal file
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."

25
skills/web-search/SKILL.md Normal file
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 "<検索したい内容や質問>"
```
検索結果を確認し、ユーザーの質問に対する回答を構築します。
- 関連性の高い情報を抽出
- 必要に応じて複数の検索結果を統合
- 情報源を明記
- 検索結果が不十分な場合は、異なるクエリで再検索を検討

136
skills/web-search/examples.md Normal file
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. **比較や分析の指示**
- 「比較して」「違いを」など、分析の観点を明確に
- 「メリット・デメリット」「使い分け」など、求める分析内容を指定

24
skills/web-search/scripts/web-search.sh Executable file
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