SKILLOfficialdevelopment

idmp-workflow-alert-create

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

説明

**IDMP（医薬品マスターデータ管理）アラート作成ワークフロー** イベントテンプレートを準備し、イベントトリガー分析を実施します。再読み込みと実行を成功として扱い、能動的なアラート発動は行いません。

原文を表示

IDMP alert creation workflow. Prepare the event template, create the Event-trigger analysis, and treat reread plus Running as success without actively triggering alerts.

ユースケース

イベントテンプレートを準備するとき
イベントトリガー分析を実施するとき

本文（日本語訳）

ワークフロー: アラート作成

あらかじめ../idmp-shared/SKILL.mdをお読みください。

推奨される参考資料

先に確認が必要な情報

アラートの意図が自然言語表現として十分で、AI による分析下書きに適しているかどうか
分析の候補名
作成成功後に下流の通知ルーティング（経路指定）がスコープに含まれるかどうか
ルーティングがスコープに含まれる場合の通知先
AI アラートプロンプトのシード（初期値）
idmp-cli ai create create --ack-risk --data '{"elementId":123,"prompt":"alert when ...","record":true}'
idmp-cli event-template events get --params '{"id":789}'
idmp-cli analysis analyses new-name --ack-risk --params '{"elementId":123,"name":"demo-alert"}'
トリガーソース
非リーフ証明境界
作成成功のみを望むのか、あるいは後から追加の下流デバッグパスを実行するのか

制約された稼働動作

try-send は作成成功に含まれない
書き込みチェーンの境界
オペレーターが自然言語から始める場合は、イベントトリガー分析に対して AI 下書きファースト（先に下書き生成）の作成を優先し、AI 下書きが不適切な場合または永続化に失敗した場合は構造化されたアラートチェーンにフォールバック（切り替え）する
event-template events get は id を使用する
analysis.analyses.new-name には候補の name と --ack-risk が必要
通知ルールを書き込む前に分析を作成または再開する
applyOnSelf=false に対して analysis trigger-types list に Event が含まれない場合は、子スコープアラート作成を強制する代わりに停止する
トリガータイプは作成適格性をゲート（判定）し、作成証明中の実際のイベントを必要としない
escalationInterval（エスカレーション間隔）を実際の通知ルール DTO（データ転送オブジェクト）と一致させる
作成成功とは、分析が作成され、再読み込みされ、Running（実行中）状態になったことを意味する
アラート作成を証明するためだけにソース属性やリプレイ履歴を書き込まない
実際のイベント発生と通知配信は、作成成功の一部ではなく、後続のオプション診断である

実行フロー

idmp-cli event-template events list、idmp-cli event-template events get --params、および再利用可能なテンプレートが存在しない場合のみ idmp-cli event-template events create --ack-risk でテンプレート側の準備をする
自然言語アラート要求の場合は、idmp-cli ai create create --ack-risk --data '{"elementId":123,"prompt":"alert when ...","record":true,"deepThinking":false,"deviceDocument":false}' で分析部分の AI 下書き生成を試し、返された下書きを id を削除して rootElementId を挿入した後、idmp-cli analysis analyses create --ack-risk --params で永続化する
AI 下書きが必要なイベントテンプレート、重大度、スコープ、または出力バインディングを保持していない場合は、現在の構造化されたアラートフローにフォールバック（切り替え）する
idmp-cli analysis analyses new-name --ack-risk --params で分析名を予約し、idmp-cli analysis trigger-types list --params でスコープサポートを証明する
必要な場合のみ idmp-cli attribute elements attributes-post --ack-risk --params を使用して不足している出力属性を作成する
idmp-cli analysis analyses create --ack-risk --params と idmp-cli analysis analyses get --params でアラート分析を作成および再読み込みする
idmp-cli analysis analyses resume --ack-risk --params で分析を再開する。成功とは analysis analyses get の再読み込みと analysis analyses resume が Running に達することを意味する
分析が既に Running 状態の場合に下流ルーティングが明示的にスコープ内にあれば、idmp-cli notification notify-rules list --params、idmp-cli notification notify-rules create --ack-risk --params、および idmp-cli notification notify-rules update --ack-risk --params で通知ルールカバレッジを検査または追加する
idmp-cli analysis analyses delete --ack-risk --params で放棄された下書きをクリーンアップする

コマンドファミリーのカバレッジについては、コア作成フローは次のステップに順番に接触します: idmp-cli event-template events list、idmp-cli event-template events get --params、idmp-cli analysis analyses new-name --ack-risk --params、idmp-cli analysis trigger-types list --params、idmp-cli attribute elements attributes-post --ack-risk --params、idmp-cli analysis analyses create --ack-risk --params、idmp-cli analysis analyses get --params、および idmp-cli analysis analyses resume --ack-risk --params。オプションの作成後ルーティングは、分析が既に Running 状態の後に idmp-cli notification notify-rules list --params、idmp-cli notification notify-rules create --ack-risk --params、および idmp-cli notification notify-rules update --ack-risk --params も使用できます。

例外パス

子スコープトリガータイプに Event が含まれない場合は直ちに停止する
AI 下書きが永続化に耐えられない、または必要な Event トリガーフィールドなしで戻ってきた場合は、下書き専用出力属性をクリーンアップし、構造化されたアラートパスから再開する
analysis analyses get --params に成功したが analysis analyses resume --ack-risk --params が分析を Running のままにしない場合は、試みを作成不完全または実行時開始境界として分類する
実際のイベント不在は、このスキルの作成失敗ではない
analysis attribute list、attribute write-data create、analysis analyses fill-history、event events list、event events confirm、および notification try-send create は、作成証明ではなく、後続のデバッグまたは配信検証に属する
証明試行が放棄された場合は、一時的な出力属性、通知ルール、または下書き分析を削除する

検証シナリオ

1. リーフオーナー厳密ライブ証明

idmp-cli analysis analyses create --ack-risk --params から idmp-cli analysis analyses resume --ack-risk --params までのチェーンを使用します。成功とは作成＋再読み込み＋Running であり、実際のイベントを開くためだけにソースデータを再生しません。

2. 中位オーナー厳密リプレイ証明

同じ作成チェーンを保持しますが、非リーフ自己分析が作成され、再読み込みされ、Running に達したことの明示的な証拠のみが必要です。トリガーサポートは作成適格性をゲート（判定）し、イベント発生を必要としません。

3. 中位子集約は `Event` が利用できない場合に停止しなければならない

まず idmp-cli analysis trigger-types list --params を実行します。applyOnSelf=false に対して Event が不在の場合は、停止して作成を強制することなく境界を報告します。

4. 新規イベントテンプレートおよび通知ルール再利用

書き込み前に、イベントテンプレートと通知ルール状態を別々に読み込みます。可能な場合は、既存の通知ルールを複製する代わりに再利用しますが、通知ルール作業は作成成功後のオプションフォローアップとして扱います。

5. テンプレートモードアラートワークフロー

テンプレートモードでも同じ証明規律を保持します: スコープチェック、作成、再読み込み、および Running。テンプレート読み込みのみでワークフローを成功として扱わず、実際のイベント発生を必要としません。

原文（English）を表示

workflow: alert create

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

Recommended references

Missing context to resolve first

Whether the alert intent is natural-language friendly enough for AI-first analysis drafting.
Candidate analysis name.
Whether downstream notification routing is in scope after create success.
Notify target when routing is in scope.
AI alert prompt seed.
idmp-cli ai create create --ack-risk --data '{"elementId":123,"prompt":"alert when ...","record":true}'
idmp-cli event-template events get --params '{"id":789}'
idmp-cli analysis analyses new-name --ack-risk --params '{"elementId":123,"name":"demo-alert"}'
Trigger source.
Non-leaf proof boundary.
Whether the operator wants only create success or an extra downstream-debug pass later.

Constrained live behaviors

try-send is not part of create success.
Write-chain boundary.
Prefer AI draft-first create for the Event-trigger analysis when the operator starts from natural language; fall back to the structured alert chain when the AI draft is unsuitable or persistence fails.
event-template events get uses id.
analysis.analyses.new-name needs a candidate name and --ack-risk.
Create or resume the analysis before you write the notify rule.
If analysis trigger-types list for applyOnSelf=false does not include Event, stop instead of forcing child-scope alert creation.
Trigger types gate create eligibility; they do not require a real event during create proof.
Keep escalationInterval aligned with the actual notify-rule DTO.
Create success means the analysis is created, reread, and Running.
Do not write source attributes or replay history just to prove alert creation.
Real event materialization and notification delivery are optional downstream diagnostics, not part of create success.

Execution flow

Prepare the template side with idmp-cli event-template events list, idmp-cli event-template events get --params, and idmp-cli event-template events create --ack-risk only when no reusable template exists.
For natural-language alert requests, try AI draft-first create for the analysis portion with idmp-cli ai create create --ack-risk --data '{"elementId":123,"prompt":"alert when ...","record":true,"deepThinking":false,"deviceDocument":false}', then persist the returned draft through idmp-cli analysis analyses create --ack-risk --params after removing id and injecting rootElementId.
If the AI draft does not preserve the required event template, severity, scope, or output bindings, fall back to the current structured alert flow.
Reserve the analysis name with idmp-cli analysis analyses new-name --ack-risk --params, then prove scope support with idmp-cli analysis trigger-types list --params.
Create the missing output attribute only if required by using idmp-cli attribute elements attributes-post --ack-risk --params.
Create and reread the alert analysis via idmp-cli analysis analyses create --ack-risk --params and idmp-cli analysis analyses get --params.
Resume the analysis with idmp-cli analysis analyses resume --ack-risk --params. Success means analysis analyses get reread plus analysis analyses resume reaching Running.
If downstream routing is explicitly in scope after the analysis is already Running, inspect or add notify-rule coverage with idmp-cli notification notify-rules list --params, idmp-cli notification notify-rules create --ack-risk --params, and idmp-cli notification notify-rules update --ack-risk --params.
Clean up abandoned drafts with idmp-cli analysis analyses delete --ack-risk --params.

For command-family coverage, the core create flow touches these steps in order: idmp-cli event-template events list, idmp-cli event-template events get --params, idmp-cli analysis analyses new-name --ack-risk --params, idmp-cli analysis trigger-types list --params, idmp-cli attribute elements attributes-post --ack-risk --params, idmp-cli analysis analyses create --ack-risk --params, idmp-cli analysis analyses get --params, and idmp-cli analysis analyses resume --ack-risk --params. Optional post-create routing can also use idmp-cli notification notify-rules list --params, idmp-cli notification notify-rules create --ack-risk --params, and idmp-cli notification notify-rules update --ack-risk --params after the analysis is already Running.

Exception paths

Stop immediately when child-scope trigger types do not include Event.
If the AI draft does not survive persistence or comes back without the required Event-trigger fields, clean any draft-only output attributes and resume from the structured alert path.
If analysis analyses get --params succeeds but analysis analyses resume --ack-risk --params does not leave the analysis in Running, classify the attempt as create incomplete or runtime-start boundary.
A missing real event is not a create failure for this skill.
analysis attribute list, attribute write-data create, analysis analyses fill-history, event events list, event events confirm, and notification try-send create belong to later debugging or delivery validation, not to create proof.
Delete temporary output attributes, notify rules, or draft analyses when a proof attempt is abandoned.

Validation scenarios

1. Leaf owner strict live proof

Use the chain from idmp-cli analysis analyses create --ack-risk --params through idmp-cli analysis analyses resume --ack-risk --params. Success is create + reread + Running; do not replay source data just to open a real event.

2. Middle owner strict replay proof

Keep the same create chain, but require only explicit evidence that the non-leaf self analysis was created, reread, and reached Running. Trigger support gates create eligibility; it does not require event materialization.

3. Middle child aggregation must stop when `Event` is unavailable

Run idmp-cli analysis trigger-types list --params first. If Event is absent for applyOnSelf=false, stop and report the boundary without forcing create.

4. New event template plus notify-rule reuse

Read event-template and notify-rule state separately before writing. Reuse a working notify rule when possible instead of duplicating it, but treat notify-rule work as optional follow-up after create success.

5. Template-mode alert workflow

Preserve the same proof discipline in template mode: scope check, create, reread, and Running. Do not call the workflow successful on template reads alone, and do not require real event materialization.

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