---
name: skill-extraction-finder
description: |
  プロジェクトのコード・設定・ドキュメントを精査し、Skillとして切り出すべきドメイン知識を発見・リストアップするスキル。
  コードに埋もれた規約・パターン・手順をSkill候補として抽出し、Skill名・description案・初期内容の骨子を提示する。
  使用タイミング:
  (1) 「Skill化すべき知識を探して」「プロジェクトからSkillを抽出して」
  (2) 新規プロジェクトでSkill設計を行いたい時
  (3) プロジェクトのSkill構成を見直したい時
  (4) 「このプロジェクトにどんなSkillがあると便利？」
---

# Skill Extraction Finder

プロジェクトファイルを精査し、Skillとして切り出すべきドメイン知識を発見する。

## 判定原則

Skillにすべき知識 = **コードから読み取りにくい** かつ **特定タスク時に必要** な暗黙知。

Skillにすべき:
- コードに散在しているが明文化されていない規約・パターン
- 特定機能に閉じた実装手順・設計判断
- 外部サービス連携の固有ルール
- プロジェクト固有の落とし穴と回避策

Skillにしない:
- コードや設定ファイルを読めば自明な情報
- 毎セッション必要な普遍的ルール（→ CLAUDE.md）
- 必ず実行すべき処理（→ Hooks）

## ワークフロー

```
1. プロジェクト構造の把握 → 2. 6つの情報源を精査 → 3. 候補の評価 → 4. レポート出力
```

### Step 1: プロジェクト構造の把握

```bash
# ディレクトリ構造（深さ3）
find . -type d -maxdepth 3 | grep -v node_modules | grep -v .git | sort

# 技術スタックの特定
ls package.json Cargo.toml go.mod pyproject.toml Gemfile *.sln 2>/dev/null

# 既存Skillの確認（重複回避）
ls .claude/skills/ 2>/dev/null
```

### Step 2: 6つの情報源を精査

詳細な調査手法は [references/discovery-sources.md](references/discovery-sources.md) を参照。

| # | 情報源 | 調査対象 | 発見できるSkill候補 |
|---|--------|---------|-------------------|
| 1 | ディレクトリ構造 | feature別ディレクトリ、モジュール境界 | 機能ドメイン別のSkill |
| 2 | 依存関係・外部サービス | package.json、SDK、API呼び出し | 連携パターンのSkill |
| 3 | コードパターン | 繰り返し出現する構造、ユーティリティ | 設計パターンのSkill |
| 4 | 設定・インフラ | CI/CD、Dockerfile、環境変数 | デプロイ・運用手順のSkill |
| 5 | テスト構成 | テストヘルパー、フィクスチャ、テスト戦略 | テストガイドのSkill |
| 6 | ドキュメント | README、docs/、ADR、コメント | 設計判断・業務ルールのSkill |

### Step 3: 候補の評価

各候補を以下で評価する:

**Skill化の価値が高い条件**:
- コードだけでは規約・意図が読み取りにくい
- 同じ領域で過去にミスや混乱が起きやすい
- 特定タスク時に毎回同じ知識が必要になる
- 複数ファイルにまたがるパターンで全体像が掴みにくい

**Skill化不要の条件**:
- 標準的なフレームワークの使い方で独自性がない
- ファイル1つ読めば分かる自己完結した実装
- プロジェクト全体で常時必要な基本ルール

### Step 4: レポート出力

```markdown
## Skill候補レポート

### プロジェクト概要
- 技術スタック: [自動検出結果]
- 主要ディレクトリ: [feature一覧]
- 既存Skills: [あれば一覧]

### Skill候補一覧

| # | 候補Skill名 | 情報源 | 価値 | 根拠 |
|---|------------|--------|------|------|
| 1 | `stripe-integration` | 依存+コード | 🔴 高 | Stripe連携が3箇所に散在、Webhook処理に固有パターン |
| 2 | `auth-flow` | コード+設定 | 🔴 高 | 認証フロー独自実装、ミドルウェア設計が複雑 |
| 3 | `deploy-staging` | 設定 | 🟡 中 | デプロイ手順が複数ステップ、環境差異あり |

### 候補詳細

#### 1. `stripe-integration` 🔴

**発見元**:
- `package.json`: stripe依存
- `src/payments/`: 決済関連コード3ファイル
- `src/webhooks/stripe.ts`: Webhook処理

**Skill化すべき知識**:
- Webhook署名検証の手順
- 冪等性の確保パターン
- テスト時のモック方法
- エラー時のリトライ戦略

**description案**:
> Stripe決済連携の実装パターン。Webhook処理、冪等性、テストモック、エラーリトライの手順を提供。
> 「決済を実装して」「Stripe連携」「Webhook処理」「課金処理」で使用。

**SKILL.md骨子**:
> - Webhook処理フロー（署名検証→イベント分岐→冪等性チェック）
> - エラーハンドリング規約
> - テストでのStripeモック手順

#### 2. `auth-flow` 🔴
...
```

IMPORTANT: レポート出力後、Skill生成はユーザー確認を得てから実行する。