--- name: pain-harvester description: 指定したドメイン・技術領域のユーザーが抱える「未解決の痛み」をインターネットから収集・分析するスキル。GitHub Issues、Stack Overflow、Reddit、フォーラム等から悲鳴を拾い集め、サービス/ツール開発やテックブログ執筆の優先順位判断に使える形で整理する。「ペインを探したい」「ユーザーの課題を調べたい」「ニーズ調査したい」「何を作るべきか知りたい」「ブログのネタを探したい」「エラーSEOのネタを探したい」「未解決の問題を調べたい」「困りごとを収集したい」で使う。 argument-hint: ドメインや技術領域（例: "Nix パッケージマネージャ", "ERP連携", "Claude Code"） --- # Pain Harvester 指定したドメインの「世界中の悲鳴を拾い集める」スキル。 ユーザーが何に困っているかを構造化して、**何を作るか・何を書くか**の判断材料にする。 ## ワークフロー概要 ``` Step 1: ドメイン定義 → Step 2: 悲鳴収集 → Step 3: 正規化・クラスタリング → Step 4: スコアリング → Step 5: レポート出力 ``` --- ## Step 1: ドメイン定義 ユーザーからドメイン/技術領域を受け取る。引数として渡されることもあれば、会話の中で明らかになることもある。 以下を明確にする: - **対象ドメイン**: 技術名、ライブラリ名、業界など（例: "Supabase RLS", "ERP XML連携", "Nix flakes"） - **目的**: サービス/ツール開発のネタ探し or テックブログ/SEOのネタ探し or 両方 - **スコープ**: 広く浅く探すか、特定の狭い領域を深掘りするか 目的が不明な場合は「両方」として進める。スコープが不明な場合はまず広く探し、後から絞る。 --- ## Step 2: 悲鳴収集 複数のデータソースから並列で検索する。**Agentツールを使って並列にサブエージェントを起動**し、各ソースを同時に調査する。 ### 検索ソースと戦略 各サブエージェントに以下の検索を割り当てる: #### サブエージェント1: GitHub Issues WebSearchで以下を検索: ``` site:github.com/*/issues "{ドメイン}" is:open "{ドメイン}" "bug" OR "error" OR "not working" OR "help wanted" site:github.com ``` 狙い: - 未解決（open）のissueで、リアクション（thumbs up）が多いもの - 同じエラーが複数リポジトリで報告されているもの - "help wanted" や "good first issue" ラベルがついた放置issue #### サブエージェント2: Stack Overflow / Q&Aサイト WebSearchで以下を検索: ``` site:stackoverflow.com "{ドメイン}" [unanswered] OR answers:0 site:stackoverflow.com "{ドメイン}" closed:no score:..3 "{ドメイン}" "no accepted answer" site:stackoverflow.com ``` 狙い: - 未回答または低評価回答しかない質問 - 回答はあるが「これでは解決しなかった」コメントがついている質問 - 質問自体のvoteが高い（＝多くの人が同じ問題を抱えている） #### サブエージェント3: Reddit / フォーラム WebSearchで以下を検索: ``` site:reddit.com "{ドメイン}" "frustrated" OR "struggling" OR "anyone else" OR "hate" site:reddit.com "{ドメイン}" "workaround" OR "hack" OR "ugly fix" "{ドメイン}" "pain point" OR "annoying" OR "wish" OR "missing feature" ``` 狙い: - 不満や苦労を表明している投稿 - ワークアラウンドを共有している投稿（＝公式の解決策がない） - 機能リクエストや「こうだったらいいのに」系の投稿 #### サブエージェント4: ブログ / Dev.to / Zenn / フォーラム WebSearchで以下を検索: ``` "{ドメイン}" "困った" OR "ハマった" OR "解決できない" site:zenn.dev OR site:qiita.com "{ドメイン}" "pitfall" OR "gotcha" OR "caveat" site:dev.to "{ドメイン}" error message -solved -fixed ``` 狙い: - 日本語圏の困りごと（Zenn, Qiita） - 英語圏の落とし穴記事（Dev.to） - エラーメッセージそのものが記事タイトルになっているもの（＝エラーSEOの種） ### 各サブエージェントへの共通指示 ``` 以下のドメインについて、ユーザーの「未解決の痛み」を収集してください。 ドメイン: {ドメイン名} 検索クエリ: {上記の検索クエリ} 各検索結果について、以下の情報を抽出してください: 1. 元の問題の要約（1-2文） 2. 元の投稿/issueのURL 3. どれくらい多くの人が同じ問題を抱えていそうか（リアクション数、類似issue数等） 4. 既存の解決策があるか（未解決/部分的に解決/ワークアラウンドのみ） 5. 元の投稿の日付（古すぎる場合は注記） 最低10件、できれば20件以上の痛みを収集してください。 類似の問題は別々にカウントしつつ、同じ問題だと注記してください。 ``` --- ## Step 3: 正規化・クラスタリング 収集した生データを構造化する。 ### 3-1: 一人称ペイン文への正規化 各ペインを以下の形式に変換する: ``` 「{ドメイン}で〜しようとすると、〜できない/〜が起きる」 ``` 例: - 「Supabase RLSでJOINを使ったポリシーを書くと、パフォーマンスが著しく劣化する」 - 「Nix flakesでプライベートリポジトリを参照しようとすると、認証が通らない」 - 「ERP XMLのエラーコード304が出ると、公式ドキュメントに記載がなく解決できない」 ### 3-2: カテゴリ分類 各ペインを以下の5カテゴリに分類する: | カテゴリ | 説明 | 例 | | --------------- | -------------------------------- | -------------------------------------------------- | | **process** | 手順・ワークフローの問題 | 設定が複雑すぎる、手順が多すぎる | | **error** | エラー・バグ・不具合 | 特定条件でクラッシュする、エラーメッセージが不明瞭 | | **missing** | 機能不足・未実装 | この機能がない、この連携ができない | | **docs** | ドキュメント不足・不正確 | 公式ドキュメントがない、情報が古い | | **performance** | パフォーマンス・スケーラビリティ | 遅い、大規模で使えない | ### 3-3: 類似ペインのクラスタリング 同じ根本原因を持つペインをグループ化する。例: - 「RLSポリシーが遅い」と「RLSでJOINすると遅い」→ 同一クラスタ「RLSパフォーマンス問題」 - クラスタ内のペイン数が多いほど、そのクラスタの重要度は高い --- ## Step 4: スコアリング 各クラスタ（ペイングループ）に4軸でスコアをつける。 ### スコアリング基準 | 軸 | 説明 | 判定方法 | | -------------- | --------------------------------------- | -------------------------------------------------------------------- | | **頻度** | 何件の独立した報告があるか | 収集データ内の件数 | | **深刻度** | どれくらい困っているか | 投稿のトーン、「blocking」「critical」等のキーワード、リアクション数 | | **未解決度** | 既存の解決策がどれだけ不十分か | 未回答、ワークアラウンドのみ、公式対応なし等 | | **機会スコア** | ビジネス/コンテンツとしての機会の大きさ | 以下のサブ指標の総合判断 | #### 機会スコアのサブ指標 - **課金意欲**: B2B/業務利用の文脈か、趣味の文脈か - **緊急性**: 「今すぐ解決しないとまずい」度合い - **検索可能性**: エラーメッセージや具体的なキーワードがあるか（SEO狙い可能か） - **解決難易度**: 自分たちが解決策を提供できそうか 各軸を 1-5 で採点し、総合スコア = 頻度 + 深刻度 + 未解決度 + 機会スコア（4-20点）で算出する。 --- ## Step 5: レポート出力 markdownファイルとして出力する。出力先はユーザーに確認するが、デフォルトはカレントディレクトリに `pain-report-{ドメイン}-{日付}.md` として保存する。 ### 出力フォーマット ```markdown # Pain Report: {ドメイン名} > 調査日: {YYYY-MM-DD} > ソース: GitHub Issues, Stack Overflow, Reddit, Zenn/Qiita/Dev.to ## サマリー - 収集したペイン総数: {N}件 - クラスタ数: {M}グループ - 最も深刻なペイン: {概要} - 最も頻出するペイン: {概要} --- ## サービス/ツール開発向け: 何を作るべきか 上位のペインクラスタを機会スコア順に並べる。 | 順位 | ペイン | カテゴリ | 頻度 | 深刻度 | 未解決度 | 機会 | 総合 | 出典数 | | ---- | -------------- | -------- | ---- | ------ | -------- | ---- | ---- | ---------- | | 1 | 「〜できない」 | error | 5 | 5 | 4 | 5 | 19 | GH×3, SO×2 | | 2 | ... | ... | ... | ... | ... | ... | ... | ... | ### 詳細: 上位ペインの深掘り #### 1. {ペイン名}（総合スコア: {N}/20） **問題の概要**: {2-3文で問題を説明} **代表的な声**: - "{元の投稿からの引用}" — [出典](URL) - "{元の投稿からの引用}" — [出典](URL) **既存の解決策と限界**: {現状のワークアラウンドとその不十分さ} **機会の分析**: {なぜこれがビジネス機会になるか。誰が金を払うか。} --- ## テックブログ/SEO向け: 何を書くべきか エラーSEOやロングテール記事のネタとしてのペインリスト。 | 順位 | キーワード/ペイン | 検索意図 | SERP状況 | 記事タイプ提案 | | ---- | ---------------------------- | ---------------- | -------------- | --------------------- | | 1 | "error code XXX" | 即座に解決したい | フォーラムのみ | 解決記事 + ツール誘導 | | 2 | "{ドメイン} {操作} できない" | やり方を知りたい | 古い記事のみ | 最新版チュートリアル | | 3 | "{ドメイン} vs {代替}" | 比較検討中 | アフィ記事のみ | 実体験ベース比較 | ### 検索意図の分類 各ネタに以下の検索意図タグをつける: - **🔥 今すぐ解決**: エラーや障害に直面中。緊急性が高く、課金意欲も高い - **📚 学びたい**: 概念や使い方を理解したい。PV狙い向き - **🔄 比較検討**: ツール選定中。信頼性のある情報を求めている - **💡 できるか知りたい**: 特定のユースケースの実現可能性を調べている --- ## 生データ: 収集した全ペイン一覧 {正規化済みの全ペインリストを、出典URLつきで列挙} ``` --- ## 実行上の注意 ### 検索クエリの調整 - ドメインが広い場合（例: "React"）は、サブドメインに分割して検索する（"React Server Components", "React hydration", etc.） - 日本語ドメインの場合は日本語検索を優先し、英語は補助的に使う - 検索結果が少ない場合は、関連キーワードや類義語で再検索する ### コスト管理 - 1回の実行で最大4つのサブエージェントを並列起動する - 各サブエージェントはWebSearch/WebFetchを使うが、深追いしすぎない（1ソースあたり最大10ページ閲覧） - 網羅性より代表性を重視する。全ての痛みを拾う必要はなく、パターンが見えれば十分 ### 鮮度の管理 - 2年以上前の投稿は「古い可能性あり」と注記する - 最新バージョンで解決済みの問題は除外するか、「要確認」とマークする ### ユーザーとの対話ポイント - **Step 1完了時**: ドメイン定義の確認。「この方向で探しますか？」 - **Step 2完了時**: 生データの量と質の報告。「十分集まりました」or「もう少し深掘りしますか？」 - **Step 5完了時**: レポートの確認。「特に深掘りしたいペインはありますか？」