known-issue-research

既知の問題の調査

コード修正ワークフローの技術分析段階で使用する、内部共有スキルです。確認済みの問題について、より詳しいコードレベルの分析の前（またはその代わり）に外部のウェブ調査が必要かどうかを判断し、調査結果に基づく対応方法を定めます。

前提条件の確認：このスキルは、フロントマターの dependencies で effective-web-research を宣言しています。読み込み時に利用可能か確認してください。利用できない場合は中止し、インストールコマンド（npx skills add FuDesign2008/open-skills -g）を出力します。暗黙のフォールバックは行いません。

ステップ番号のパラメーター化

このスキルは、ステップ番号の異なるワークフローで共有されます。以下のジャンプ先はすべてプレースホルダー（{impact-assessment step}、{root-cause step}、{upstream-eval step}）で記載します。参照するワークフローでは、参照箇所に独自の番号を明記します（例：「ステップ 4 に進む」）。このスキル内にワークフローのステップ番号をハードコードしないでください。

1. 調査先の振り分け

問題の存在が確認できたら、直ちに実行します。根本原因がどの分類に当てはまる可能性が最も高いかを判断します。これは後続ステップの優先度を調整するものであり、後続ステップを置き換えるものではありません。

ルート	シグナル	重視する点
🟢 内部優先	「自分たちのコード／ロジック／規約」に関する問題、または根本原因がこのリポジトリにあると疑われる場合	まずコードの場所を確認します。クイック検索（§2）は任意の代替手段で、根本原因分析が中心です
🔵 外部優先	サードパーティのライブラリ／フレームワーク／APIの名称とバージョンが指定されている場合、「使い方／理由／既知の問題」を尋ねている場合、または§2のトリガーに該当する場合（プラットフォームでの無反応な失敗／ネストされたホスト／コードレベルで疑わしい箇所がない）	クイック検索（§2）を主要なアクションとし、まず既知の事例を検索します
🟣 ハイブリッド（外部から内部へ）	外部の概念と内部のオブジェクトが組み合わさっている場合（「使用しているXライブラリに脆弱性Yがあるか」「パターンXを自分たちのコードに適用する」など）	まず§2で外部から概念を理解し、その後、適用に向けて内部の根本原因分析を行います

判断に迷う場合は、デフォルトで 🟢 内部優先 とします（これらのワークフローはコードを変更するためのものであり、根本原因の多くはリポジトリ内にあります）。

effective-web-research のステップ0との関係：そちらの振り分けでは、単一の検索を外部に向けるべきかを判断します。こちらでは、問題全体の調査構成を判断します。両者は互いに補完するものです。判断に迷う場合は、そちらのステップ0も参照してください。

2. 既知の問題のクイック検索

トリガー（いずれか1つに該当する場合。🔵／🟣のルーティングでは主要なアクション、🟢ではコードに計測機能を追加する前の任意の代替手段です）：

• プラットフォーム／ネイティブコンポーネント（Android WebView、iOS UIPickerView、ブラウザーAPI、OSレベルのコントロールなど）が関与し、無反応な失敗が発生している。エラーもクラッシュもなく、呼び出しは正しいのに、まったく反応しない。
• フロントエンドのロジックが完全に正しいように見える一方で、ネストされたホストランタイム（React Native、Electron、Cordova、WebView-in-Appなど）を使用している。
• コードレベルで疑わしい箇所がない：呼び出しチェーンは完結し、パラメーターも正しく、ログにも実行が記録されているのに、ランタイムでは動作しない。

実行：StackOverflow、GitHub Issues、公式ドキュメントを対象に、「症状のキーワード＋プラットフォーム／フレームワーク＋年」で WebSearch を実行します。並行して行うアクション（サードパーティのライブラリ／フレームワークが明示されている場合、または症状がプラットフォーム固有の挙動と強く関連している場合は必須）：上流依存関係の Changelog／Release Notes／Issues を確認し、すでに修正済みのバージョンがないか調べます。アップグレードが最も簡単な修正になる場合があります。ワークフローの {upstream-eval step} に引き継ぎます。ここでは upstream-dependency-debug に委任します。

結果の扱い：

結果	アクション
✅ 既知の事例が見つかり、根本原因が明らか	クイック検索の結論を出力し、根本原因分析を省略して {impact-assessment step} に進みます
✅ 上流で修正済みのバージョンが見つかった	手がかりを出力し、アップグレードの実行可能性を評価するため {upstream-eval step} に進みます（上流で修正済みという手がかりは、まだ解決策ではありません）
⚠️ 関連する議論が見つかり、根本原因が一部明らか	調査結果を参考情報として {root-cause step} に渡します
❌ 何も見つからない	何も出力せず、{root-cause step} に進みます

2.1 パフォーマンスパターンのバリエーション（perf-optimize-workflow 向け）

参照先のワークフローがパフォーマンス分析（perf-optimize-workflow）の場合、§2 を既知のパフォーマンスパターンのクイック検索として扱い、ワークフローの仮説段階に入る前に、次の追加トリガーのいずれかに該当する場合に実施します。

• 異常箇所は特定できたものの、ワークフローの既知のパフォーマンステーブルに分類できない
• フレームワーク／ライブラリのパフォーマンス上のバグまたは制限が疑われる（フレームワーク名とバージョンが特定されている）

実行：§2 と同じ WebSearch の手順に従い、クエリの形式は symptom + framework/lib + version + year とします。GitHub Issues、公式の変更履歴、StackOverflow を優先してください。

結果	対応
✅ 既知の事例／バージョンのバグ	既知の修正方法を解決策候補として提示し、以降の仮説検証ではその方向に重点を置きます
⚠️ 関連する議論はあるが、結論は出ていない	仮説の方向性に反映します
❌ 見つからない	何も報告せず、ワークフローの次の段階に進みます

perf-optimize-workflow は独自のパターンテーブルと段階のオーケストレーションを維持します。このサブセクションで扱うのは検索方法のみです。

3. 業界全体の問題の評価

トリガー（任意の悲観的な分岐）：根本原因が、明らかなアプリケーション層の回避策がない、プラットフォーム／言語／プロトコル／標準の厳しい制限（例：ブラウザーのセキュリティポリシー、JS のシングルスレッド性、プロトコルの制約）に明確に起因している場合です。

実行：WebSearch — これは業界全体で認知されている問題でしょうか？ 主流のフレームワークや大手企業はどのように対処しているでしょうか？ 実用的な回避策は存在するでしょうか？

結果の扱い：

結果	対応
🚫 広く認知された厳しい問題で、実用的な解決策がない	評価レポート（テンプレートは reference.md）を出力し、ユーザーの判断を待ちます（回避策を探す／現状を受け入れる）
⚠️ 制限はあるものの、回避策が存在する	解決策の検討で回避策を候補として提示し、続行します
✅ 業界全体の問題ではなく、修正可能な問題	{impact-assessment step} に進みます

§2 との違い：§2 は根本原因を特定する前に、症状から既知の事例を検索します（解決策の有無にかかわらず適用します）。§3 は根本原因が明らかになった後に、業界で認知された解決策があるかどうかを評価します（解決策がない場合を想定しています）。両者が重複することはありません。

WebSearch の手順

このスキルで WebSearch を実行する際は、すべて effective-web-research に従います。まずその Step 0 のトリアージ（質問が外部の情報に関するものであり、リポジトリから解決できないことを確認する）を行い、次にその 4 つの原則（権威ある情報源を優先／情報の鮮度を確認／重要な主張を複数の情報源で検証／コンテンツファームを避ける）を守ります。ユーザーが厳密さを求める場合は、厳格モードに切り替えてレポートを作成してください。検索前に、そのスキルの最新のドキュメントを読んでください。記憶を頼りにしてはいけません。

統合ガイド（参照するワークフロー向け）

• frontmatter の dependencies でこのスキルを宣言します。不足している場合は、起動時に中断してください。
• 参照行には、上記のプレースホルダーに対するステップ番号の対応関係と、§2／§3 をどのステップに組み込むかを記載してください。
• 意味上のバリエーションは、各自の本文に記載してください。例：jira-fix-workflow では、§3 はゲート（任意ではない）、🚫 の結果はフローを停止して Jira コメントを作成し、レポートのテンプレートは独自の reference.md に置きます。