analysis-core

Analysis Core

内部共有スキルです。PDCA 修正ワークフローで使用する分析段階の手法の唯一の信頼できる情報源です。各ワークフローは独自のオーケストレーション（終了条件、手動／自動モード、OpenSpec／Jira の成果物の出力先、意図的な相違点）を維持します。

前提条件の確認：このスキルはフロントマターで強い依存関係を宣言しています。読み込み時に、それぞれが利用可能か確認してください。1 つでも利用できない場合は中止し、インストールコマンド（npx skills add FuDesign2008/open-skills -g --skill '*' --yes）を出力してください。黙って代替手段に切り替えてはいけません。

プレースホルダーの契約

このスキルは、ステージ番号が異なるワークフロー間で共有されます。ここでワークフローのステージ番号やタイトルをハードコードしてはいけません。

プレースホルダー	意味	対応するマッピング担当
{next-stage}	分析の終了ゲート後／計測の解決後に移行するステージ	参照元ワークフロー。参照行でマッピングします（番号＋名前）
{root-cause step} / {impact-assessment step} / {upstream-eval step}	known-issue-research における分析ステージ内のステップ番号	同じ参照行（既存の known-issue-research 契約）

1. 一時変更の許可とロールバックゲート

分析はデフォルトで読み取り専用です。分析支援目的の編集のみ許可されます。これらはすべて登録し、{next-stage} に進む前に完全にロールバックする必要があります。修正の実装はワークフローの実行ステージで行い、ここでは行いません。

許可されるもの（分析支援目的のみ）：

• 計測、一時ログ、再現スクリプト
• 仮説検証のための編集（例：挙動を観察するために条件を反転させる）—検証後に元に戻します

**禁止事項：**修正の実装を目的とする編集。

**登録（必須）：**一時編集を行うたびに、ファイル＋場所＋元の内容＋目的（ロールバックの根拠）をすぐに記録してください。

終了ゲート（{next-stage} に進む前に完了必須）：

1. 登録内容に基づき、元の状態を1つずつ復元します（登録内容が正です。git diff は登録項目が解消されていることの確認にのみ使用してください。作業ツリーにはすでにユーザーの編集が含まれている場合があります）
2. 「临时改动清单 + 回滚验证」を出力します
3. ロールバックされていないものが残っている場合は、{next-stage} に進んではいけません。編集を残すには、ユーザーの明示的な確認が必要です
4. §5 の分析ゲート出力ブロックでステージの出力を締めくくります（一時変更の行にこの一覧を記載します）

ツールの制限（分析ステージ）：✅ Read/Grep/SemanticSearch；✅ WebSearch（調査の振り分け／クイック検索／upstream-eval／runtime-evidence-debug の例外的な使用）；✅ 上記の分析支援目的の編集に限り、Edit/Write を使用可；✅ 読み取り専用の検証コマンドに限り、Bash を使用可 — デバッグ実行や再現手順のためにアプリを実行するには、ユーザーの確認が必要です（§3 を参照）。

2. 分析ステップの概要

1. 存在確認（ゲート — 常に最初に実施）

   • Read/Grep/SemanticSearch を使って関連コードを特定します
   • 判定に基づいて対応します：

   判定	アクション
   ✅ 問題が存在する	ステップ 2 → 3–8 に進みます
   ❌ 問題が解消している	すでに修正済み、またはロジックが変更された可能性があることを、該当箇所を示して報告し、停止してユーザーの指示を待ちます
   ⚠️ 説明とコードが一致しない	不一致を報告し、ワークフローの問題明確化ステージに戻ります

2. 調査ルート — known-issue-research を読み込み、その手順（トリアージ＋既知問題のクイック検索＋業界全体の評価）に従います。参照元ワークフローの参照行に {root-cause step} / {impact-assessment step} / {upstream-eval step} の対応関係が記載されています。報告テンプレート：known-issue-research/reference.md。

3. 現象 — 再現条件／手順を確認します。問題をブラウザーで再現できる場合は、browser-debug-toolkit を使って実行時の状態を再現・観察することを優先します（UI/CSS/DOM に限りません。ブラウザー自動化を利用できない場合は、そのスキルの縮退パスに従います）。

4. 特定 — ファイルパスと行番号、主要な関数／クラスを示します。

5. レッド実行可能ループのゲート（複数の仮説を立てて根本原因を推測する前に実施）

   • レッド実行可能ループとは、エージェントが実行可能な決定論的な失敗再現（コマンド、テスト、または同等の観測された失敗）であり、この分析ステージで少なくとも一度は実行され、失敗状態が観測されているものです。
   • ユーザーが報告した症状（貼り付けられたログ、口頭での説明、スクリーンショット）は、エージェントが観測したレッドには該当しません。
   • 存在しない場合： 推測に基づく複数の「考えられる根本原因」の一覧を出してはいけません。まずループを確立します（§3 に従って再現手順と計測を行います）。エージェントが実行可能なループを確立できない場合、エスケープ方法は、runtime-evidence-debug の人間と AI の役割分担に従って、計測と再現手順をユーザーに引き継ぐ形で明示する必要があります。または、ギャップを明記して停止します。黙って問題なしとしてはいけません。
   • 存在する場合： ステップ 6 に進みます。このステージの出力は、§5 の分析ゲート出力ブロック（レッドループの行を含む）で締めくくります。

6. 根本原因 — データフローと呼び出しチェーンを分析します。反証可能な仮説を立てられるのは、ステップ 5 を満たした後に限ります。

7. 上流依存関係の修正評価（任意） — 根本原因が上流依存関係のバグである場合、またはステップ 2 で上流の修正済みバージョンが見つかった場合は、upstream-dependency-debug を読み込み、その手順に従います。結果：リスクの低いアップグレード → 解決策の検討でアップグレードを推奨します。リスクが高い → 回避策と併せてアップグレードを列挙します。未修正 → 回避策に一時的なものと明記します。

8. 影響 — 影響を受けるモジュール／機能を示します。

存在確認に失敗した場合、または説明とコードが一致しない場合は、解決策の検討に進んではいけません。

分析ステージの危険信号

• 調査ルートが 🔵/🟣 なのに既知問題のクイック検索を省略している、または 🟢 でクイック検索のトリガーに該当しているのに「まずコードを読む」という理由で WebSearch を省略している
• 根本原因にサードパーティのライブラリ／フレームワーク名を挙げているのに、回避策を次々と提示する前に上流の Changelog/Release Notes を確認していない
• 修正を加えるために「分析」を利用している — 仮説検証を超える一時的な編集、またはロールバックせずに {next-stage} に進む
• 一時的な編集が記録されていない、または {next-stage} に進む前に「临时改动清单 + 回滚验证」が欠けている
• レッド実行可能ループがないのに、複数の根本原因の推測を提示している（または、ループを実行できないことをユーザーに明示していない）

3. 計装デバッグ（ランタイム観察 — デフォルトのエントリーポイント）

状態ベースのトリガー（いずれか1つ。{next-stage} に進む前に適用することを推奨）：

• 静的解析が行き詰まった — モジュールの概要はおおむね把握できているものの、コードを読んでも具体的な仕組みや経路を確認できない
• 再試行／継続 — 静的解析に基づく修正を適用したが、問題が残っている
• サイレント失敗 — 呼び出しチェーンとログは正しく見えるが、動作が誤っている
• 修正の検証に、実行時の前後の証拠が必要

デフォルトのエントリーポイント：いずれかのトリガーが発生したら、まず runtime-evidence-debug を読み込み、そのライフサイクル（エスカレーションの判断 → 計装の設計 → 再現 → 証拠のティア → 信頼度の判定 → エスケープハッチ → 修正の検証）に従います。エントリーは状態に基づく判断（「ランタイム観察が必要」）であり、自己評価による信頼度の判定ではありません。スキル独自の「静的解析を優先する」エスカレーション判断が引き続き優先されます。

シナリオの組み合わせ（必要に応じて適用。それぞれの権限は独立しています）：

• ブラウザーで再現可能 → 計装におけるツール選択は browser-debug-toolkit に委ねます。現象の把握段階ですでにブラウザーで再現している場合は、静的解析がまだ行き詰まっているときに限り、ここで続行します
• ハイブリッドアプリ（ネイティブシェル + WebView/WKWebView/Electron + H5）→ 計装の前に、レイヤーの特定について hybrid-debug を参照します
• 実機での観察 → チャネルを有効にするスキルを組み合わせます（例：接続を確立するために android-webview-debug を使用）。何を観察するか、どの証拠ティアを使うか、どの時点で信頼度が十分かは、runtime-evidence-debug が判断します

実行の詳細、信頼度の判定、エスケープハッチは各スキルの最新の SKILL.md に記載されています。実行前に読んでください。

ツールの制限： ✅ 計装箇所の選定には Read/Grep を使用します。計装と検証の編集は §1 に従います（AI は計装を追加でき、必ず登録する必要があります）。❌ ユーザーの確認なしに再現手順を実行しないでください。

4. デバッグ検証ループ（検証段階）

分析段階でデバッグスキルを使用して根本原因を特定した場合、ワークフローの検証段階では、テストだけに頼らず、同じスキルを使用して修正を検証する必要があります。

• ブラウザーで再現可能（browser-debug-toolkit）→ 同じスキルを使用し、実行時の状態を修正前後で確認します（DOM / 計算済みスタイル / ボックスモデル / コンソール / ネットワーク）。異常が解消したことを確認します
• ランタイムの証拠（runtime-evidence-debug）→ 元の計装箇所を再確認し、修正前後の証拠を比較します。異常な動作が解消したことを確認します
• ハイブリッド（hybrid-debug）→ 影響を受けるレイヤー（L1–L4）を検証し、新たなレイヤー間の副作用がないことを確認します

5. 分析ゲートの出力ブロック（必須の段階終了ブロック）

{next-stage} に進む前に、これを参照するすべてのワークフローの分析段階の出力を締めくくるブロックの唯一の信頼できる情報源です。ワークフローでは簡潔な参照のみを記載し、項目を再掲しません。

【Analysis gate / 分析门控】
Red loop: ✅ <command + one-line red evidence observed this stage> / ❌ <why unestablished + handoff already proposed: instrumentation/repro steps handed to the user>
Debug entry: runtime-evidence-debug loaded (trigger: static stalled / retry / silent failure / before-after verification) / not needed (one-line Tier 1–2 evidence)
Scenario supplements: browser-debug-toolkit / hybrid-debug / channel enabler (e.g. android-webview-debug): engaged(<which>) / not needed
Temporary changes: none / <registered list + rollback verified>

ルール：

• ブロックがない、または未記入の場合、{next-stage} への移行はできません。記入することが移行条件であり、項目を記入できないこと（例：レッドループ）は、それ自体がエスカレーションのシグナルです。
• 「不要」と記入することはできますが、その場合は1行の証拠が必要です。空欄や曖昧な記入は認められません。
• レッドループの項目は §2 のステップ 5 に従います（ユーザーが貼り付けた証拠では要件を満たしません）。デバッグへのエントリー項目は §3 に従います（状態ベースのトリガー）。

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

• frontmatter の dependencies に analysis-core を宣言し、見つからない場合はワークフローの開始時に中断してください。
• 簡潔な参照形式（推奨）： {next-stage} と既知の問題を調査するステップの対応関係（番号と名前のみ）を含む「analysis-core に委任」ブロックを1つだけ記載してください。§§1–3 の説明を繰り返したり、分析ステップの骨組みを再掲したりしないでください。
• ワークフロー本体に残す内容： オーケストレーションのみ（終了条件／モード、OpenSpec／Jira の出力先、意図的な差異（形似神异）、難易度／パスの表）。
• 検証ステージ： §4 を参照する1行を記載してください。デバッグ検証の箇条書きは貼り付けないでください。
• reference.md： 方法論についてはこのスキルを参照し、ワークフロー固有の出力テンプレートは残してください。ゲートの説明を重複させないでください。
• 意図的な差異（カバレッジゲートの厳格さ、テストスイートの確実な実行をブロックする条件、業界評価の Jira ゲートなど）を、このスキルに持ち込まないでください。