claude-skills/

Anthropic公式スキル・プラグインの日本語ディレクトリ

last sync 1h ago
スキルOfficialdevelopment

🐛idmp-workflow-alert-debug

プラグイン
idmp-plugin
ソース
GitHub で見る ↗

説明

IDMP アラート（警告通知）デバッグ（問題調査）ワークフロー オペレータチェーン（複数の処理ステップの連鎖）をイベント件数と詳細から始めて、以下の順で追っていきます： - コンテキスト（背景情報） - 確認応答 - 再送信 - 注釈（メモ・補足） - 通知ルール - 配信履歴

原文を表示

IDMP alert debugging workflow. Walk the operator chain from event count and detail to context, acknowledgement, resend, annotations, notify rules, and delivery history.

ユースケース

  • ✓IDMPアラートをデバッグする
  • ✓イベント件数と詳細から問題を調査
  • ✓ワークフローの処理ステップを追跡

本文（日本語訳）

ワークフロー：アラートのデバッグ

最初に ../idmp-shared/SKILL.md をお読みください。

推奨される参考資料

最初に確認すべき不足情報

  • エラーの発生範囲（障害境界）
  • 再確認対象の期間（読み込みウィンドウ）
  • イベントの対象範囲
  • 通知ルールの対象範囲
  • 問題が「イベントが開かれていない」のか「イベントは開かれたが配信に失敗した」のか

制約のある実行時の動作

  • confirm（確認）と resend（再送信）には副作用がある
  • オペレーターが開いたイベントを必要とする場合、status=Unackが最も安全なデフォルト値
  • イベントをアラート作成時点までさかのぼって関連付ける際は、analysisIdを優先する
  • 通知履歴は再送信より遅れる可能性がある
  • 有効なデバッグの過程で、リンクされた分析がすでに削除されている場合がある
  • 確認や再送信の操作を行う前に、イベントの証拠（根拠）を記録する

実行フロー

  1. idmp-cli event count list と idmp-cli event events list --params から始めて、エラーがイベントの欠落なのか配信の欠落なのかを判断する

  2. idmp-cli event events get --params と idmp-cli event events items --params を使って、1つのイベントとそのペイロード（データ内容）を確定する

  3. 証拠を記録した後に限り、idmp-cli event events confirm --ack-risk --params または idmp-cli event events resend --ack-risk --params の実行を検討する

  4. idmp-cli notification config list を読んで、通知側が正しく設定されているか確認する

  5. idmp-cli notification page list --params でイベント側の確認後の配信履歴を調べて完了する

例外的な処理経路

  • イベントが存在しない場合は中止し、アラート作成または分析の診断を担当者に引き継ぐ
  • 再送信直後に配信履歴が空の場合は、失敗と宣言する前に履歴の遅延を指摘する
  • デバッグ用に一時的に作成した成果物は、ワークフロー終了前に削除する

確認シナリオ

1. イベントが存在し、アラートを説明できる場合

idmp-cli event events list --params の後に idmp-cli event events get --params を使う。結果はアラートが開かれたこと、および現在のイベントの内容を証明するべき。

2. イベント状態を変更しない配信の失敗

idmp-cli notification config list と idmp-cli notification page list --params を、イベント状態を変更せずに使う。このパスは診断のみが目的。

3. 証拠を記録した後の確認と再送信

idmp-cli event events items --params を読んだ後に限り、idmp-cli event events confirm --ack-risk --params を使う。状態の変更はデバッグの最初のステップではない。

4. 一時的なデバッグ注釈のライフサイクル

デバッグ中に一時的なメモを追加した場合は、削除計画を明示的に立てる。一時的な成果物が削除されるまで、ワークフローは未完了。

5. イベントが存在しない場合

idmp-cli event count list と idmp-cli event events list --params から開始する。両方の結果がイベント不在を示す場合は中止し、上流の発生範囲を報告する。再送信が実際に実行された場合のみ、その後で notification page list を再度確認する。

原文（English）を表示

workflow: alert debug

Read ../idmp-shared/SKILL.md first.

Recommended references

Missing context to resolve first

  • Failure boundary.
  • Reread window.
  • Event scope.
  • Notify-rule scope.
  • Whether the complaint is “no event opened” or “event opened but delivery failed”.

Constrained live behaviors

  • confirm and resend have side effects.
  • status=Unack is the safest default when the operator needs an open event.
  • Prefer analysisId when correlating an event back to alert creation.
  • Notification history can lag behind resend.
  • A linked analysis was already deleted in some valid debug branches.
  • Capture event evidence before any acknowledge or resend action.

Execution flow

  1. Start with idmp-cli event count list and idmp-cli event events list --params to decide whether the failure is missing events or missing delivery.
  2. Use idmp-cli event events get --params and idmp-cli event events items --params to lock a single event and its payload.
  3. Only after evidence is captured should you consider idmp-cli event events confirm --ack-risk --params or idmp-cli event events resend --ack-risk --params.
  4. Read idmp-cli notification config list to confirm the notification side is configured.
  5. Finish with idmp-cli notification page list --params to inspect delivery history after the event-side review.

Exception paths

  • If no event exists, stop and hand off to alert creation or analysis diagnosis.
  • If delivery history is empty right after resend, call out history lag before declaring failure.
  • Any temporary debug artifact must be deleted before you leave the workflow.

Validation scenarios

1. Event exists and explains the alert

Use idmp-cli event events list --params, then idmp-cli event events get --params. The result should prove the alert opened and what the event currently says.

2. Delivery failure with no mutation

Use idmp-cli notification config list and idmp-cli notification page list --params without changing event state. This path is for diagnosis only.

3. Acknowledge and resend with evidence captured

Only after reading idmp-cli event events items --params should you use idmp-cli event events confirm --ack-risk --params. Mutation is never the first debugging step.

4. Temporary debug annotation lifecycle

If you add any temporary note while debugging, plan its cleanup explicitly. The workflow is still incomplete until the temporary artifact is removed.

5. No event exists

Start with idmp-cli event count list and idmp-cli event events list --params. If both prove there is no event, stop and report the upstream boundary. Reread notification page list after resend only when resend was actually executed.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。