diagnostics-report-analyzer-skill

診断レポート分析スキル

AvdLee Diagnostics フレームワークが生成する単一ファイルのレポートを分析するには、このスキルを使用します。通常、これらのレポートは .html 添付ファイルとしてメールで送信され、構造化 JSON とブラウザーレンダラーの両方が含まれる場合と、古い形式の事前レンダリング済み HTML のみが含まれる場合があります。

基本原則

レポートは要約対象のウェブページではなく、診断の証拠として扱います。新しいレポートはエージェント向けに意図的に設計されています。レンダリング済み HTML よりも精度が高く、トークン効率に優れた構造化 JSON ペイロードが含まれています。

分析ワークフロー

1. 埋め込み JSON を優先する

レポートに次の要素が含まれている場合は、そのテキストコンテンツを抽出して解析します。

<script id="diagnostics-report-data" type="application/json">

この JSON を信頼できる情報源として使用します。章で legacyHTML が明示的に使用されている場合を除き、CSS、JavaScript、ナビゲーションのマークアップ、レンダリング済み HTML は無視します。

想定されるトップレベルフィールド：

• schemaVersion：レポートのスキーマバージョン。
• title：人が読めるレポートのタイトル。
• agentHints：生成元が提供する分析のヒント。
• chapters：レポートの各セクション。

想定される章の形式：

• showTitle：ブラウザーでのレンダリングに関するヒント。分析には影響しません。
• kind: "logs" と data.sessions。
• kind: "table" と data.rows。
• kind: "text" または kind: "preformatted" と data.value。
• カスタム診断またはフォールバックコンテンツ用の kind: "legacyHTML"。
• カスタムのブラウザーレンダリングが必要な章用の任意の表示 HTML である legacyHTML。分析には、data.type が legacyHTML である場合、または構造化フィールドで質問に答えられない場合を除き、data を優先します。

2. レガシー HTML にフォールバックする

JSON の script タグがない場合は、HTML レポートを直接解析します。

• セッションログは通常、#log-sessions 内にあります。
• セッションは通常、.collapsible-session details で囲まれています。
• セッションのメタデータは、多くの場合、<summary><div class="session-header">... 内にあります。
• ログレベルは通常、.debug、.error、.system、.crash で表されます。
• 古いレポートでは、SYSTEM: *** Terminating app due to uncaught exception... や SYSTEM: *** First throw call stack: のような system 行にしかクラッシュが示されないことがあります。
• 古い形式のプレーンなセッションでは、区切りのようなコンテンツや <pre> ブロックが使われていることがあります。

フォールバック解析は対象を絞ってください。小さなセクションで質問に答えられる場合は、HTML ファイル全体を読み込んだり、内容をすべて言い換えたりしないでください。

3. 証拠を優先する

次の順序で分析します。

1. agentHints があれば読みます。
2. アプリ／システムのメタデータを調べ、アプリのバージョン、ビルド、OS、デバイス、ロケール、環境を確認します。
3. 新しいセッションから順に調べます。
4. crash イベント、error イベント、MetricKit 診断、通常と異なるシステムログの順に優先します。
5. セッションに crash イベントがない場合は、クラッシュに似た system 行をレガシーなクラッシュの証拠として扱います。ただし、構造化された crash イベントも存在する場合は、そちらを優先します。
6. 回帰や繰り返し発生するパターンの説明に役立つ場合に限り、失敗したセッションと古いセッションを比較します。
7. カスタム章を調べ、機能フラグ、ユーザーデフォルト、ディレクトリツリー、設定、アカウント状態、キャッシュファイルなど、ドメイン固有の状態を確認します。

出力形式

ユーザーが別の形式を指定しない限り、次の形式で回答します。

## Summary
One or two sentences describing what most likely happened.

## Evidence
- Specific session, timestamp, event level, metadata row, or chapter detail that supports the conclusion.
- Another relevant detail if needed.

## Recommended Next Steps
- Concrete debugging or support action.
- Code/config area to inspect if apparent.

最も可能性の高い説明から始めます。証拠から結論を出せない場合は、その旨を伝え、判断を分けるために不足している情報を列挙します。

トークンの節約

診断レポートは大きい場合があります。必要な箇所に絞ってください。

• 生の HTML よりも、埋め込み JSON ペイロードを優先します。
• 新しいセッションとクラッシュ／エラーイベントから確認します。
• ノイズの多いシステムログ／デバッグログは、個々のエントリを引用する前にパターンで要約します。
• 結論を直接裏付ける短い抜粋だけを引用します。
• ユーザーから明示的に求められない限り、生のログを大量に出力しないでください。

互換性に関する注意事項

新しい Diagnostics レポートには、アプリの更新前に過去のログがデバイスに保存されている場合、構造化セッションとレガシーセッションが同じペイロードに含まれることがあります。どちらも有効な証拠として扱ってください。

レガシー HTML チャプターには、Diagnostics フレームワークが生成した信頼できるレポート用マークアップが含まれている場合があります。構造化データを利用できない場合はこれらを使用し、JSON ペイロードがある場合は、引き続き優先される機械可読インターフェースとして扱ってください。