スキルOfficialdevelopment

🚀idmp-workflow-asset-bootstrap

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

説明

IDMP（医薬品マスターデータ統合・管理）資産の初期化ワークフロー。モデリングやデータ取り込みのための書き込み処理を実行する前に、まず以下を読み込みます： - ルート（基盤となるディレクトリ構造） - パス（データの格納位置） - テンプレート（ひな形） - 属性テンプレート（データ項目の定義ひな形） - UOM（計測単位） - データソース（データの出所） - レコード表示権限（各情報へのアクセス権限）

原文を表示

IDMP asset bootstrap workflow. Read roots, paths, templates, attribute templates, UOMs, datasources, and record visibility before any modeling or ingestion write.

ユースケース

✓IDMP資産の初期化を行うとき
✓モデリング前の基盤設定
✓データ取り込み前の準備

本文（日本語訳）

ワークフロー: アセット初期化

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

参考資料

先に確認すべき不足情報

操作者がモデル化の対象にしたい、実際に見えるビジネス上の最上位階層またはパス
目的が「末端のみの範囲」「中間管理者の範囲」「データ取り込み元の範囲」のどれか
再利用可能なテンプレート体系（ひな型の系列）がすでに把握されているかどうか

実行時の制約事項

最上位階層の特定は、推測した「デモ」の階層ではなく、実際の環境の証拠に基づく必要がある
テンプレートと部分テンプレートの確認は、モデル化の仮定を立てる前に実施する
測定単位とデータソースの確認は、オブジェクトの変更可能性ではなく、測定の意味づけとデータ取り込みの可視性を証明する
ダウンストリーム（後工程）のワークフローが一時的に中間管理者階層を作成し、その後の自動削除タスクが「失敗」状態で終わった場合、破壊的なクリーンアップループの再試行理由ではなく、再読み込み検証後のバックエンド側の片付け境界として扱う

実行フロー

idmp-cli element elements list --params、idmp-cli element elements path --params、idmp-cli element fullpath get --params、idmp-cli element by-path list --params を使い、見える最上位階層と選定した管理者を確定する
idmp-cli template elements list --params と idmp-cli element elements sub-templates --params を使い、その範囲の背後にあるテンプレート体系を確認する
idmp-cli attr-template elements attributes --params を使い、測定準備の整った属性テンプレートを検査してから、分析やダッシュボード作成を提案する
idmp-cli uom uomclasses list と idmp-cli uom uom search --params を使い、測定の意味づけを確認する
idmp-cli datasource connections list、idmp-cli data first-level-elements list、idmp-cli data records list を使い、データ取り込みの可視性を確認する

例外的な処理経路

見える最上位階層が空の場合、認証、権限、環境スコープの問題に分類してから進める
選定した最上位階層が誤ったテンプレート体系を示す場合、後工程のワークフローに無理に進めず、別の管理者を選択する
データ取り込みのトレースが見えない場合、ダウンストリームでのインポートやアラート成功を約束しない
過去の一時的階層クリーンアップタスクが失敗したが管理者がまだ読み取り可能な場合、最上位階層インベントリが変わったと見せかけずに、環境をクリーンアップの注意書き付きで再利用可能として分類する

検証シナリオ

1. 未知の環境での初期化

idmp-cli element elements list --params と idmp-cli element elements path --params から始める。目的は、他の何よりもまず現在見える最上位階層を証明することである

2. モデル化は完成しているがデータ取り込みが未確認の環境

idmp-cli attr-template elements attributes --params でテンプレート準備を証明し、その後 idmp-cli datasource connections list でデータ取り込みの可視性を別途確認する

3. 最上位階層のリストが空

idmp-cli element elements list --params が有用な結果を返さなかった時点で停止する。次のステップは推測による初期化ではなく、認証または権限の診断である

4. 選定した最上位階層でのテンプレート不一致

idmp-cli template elements list --params と idmp-cli element elements sub-templates --params で不一致を示す。テンプレート互換性を無理に作り出さずに、管理者を切り替える

5. 書き込み後の再読み込み

過去の操作者がすでに一時的なオブジェクトを作成した場合、環境が再利用可能と主張する前に、idmp-cli data first-level-elements list と idmp-cli data records list で再読み込みする。オブジェクトが過去の自動削除タスク失敗によってのみ読み取り可能な場合は、ここでクリーンアップ再試行をするのではなく、バックエンド側のクリーンアップ注意書きとして記録する

原文（English）を表示

workflow: asset bootstrap

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

Recommended references

Missing context to resolve first

The visible business root or path the operator wants to model against.
Whether the goal is leaf-only context, middle-owner context, or source-ingestion context.
Whether a reusable template family is already known.

Constrained live behaviors

Root discovery must be real-environment evidence, not a guessed demo tree.
Template and sub-template checks come before any modeling assumption.
UOM and datasource checks prove measurement semantics and ingestion visibility, not object mutability.
If a downstream workflow temporarily creates a middle-owner hierarchy and the async delete task later lands in FAILED, treat that as a backend cleanup boundary after the reread proof instead of a reason to keep retrying destructive cleanup loops.

Execution flow

Use idmp-cli element elements list --params, idmp-cli element elements path --params, idmp-cli element fullpath get --params, and idmp-cli element by-path list --params to lock the visible root and chosen owner.
Use idmp-cli template elements list --params and idmp-cli element elements sub-templates --params to confirm the template family behind that scope.
Use idmp-cli attr-template elements attributes --params to inspect measurement-ready attribute templates before proposing analysis or panel work.
Use idmp-cli uom uomclasses list and idmp-cli uom uom search --params to verify measurement semantics.
Use idmp-cli datasource connections list, idmp-cli data first-level-elements list, and idmp-cli data records list to confirm ingestion visibility.

Exception paths

If visible roots are empty, classify the issue as auth, permission, or environment scope before continuing.
If the chosen root exposes the wrong template family, stop and pick a different owner instead of forcing later workflows.
If ingestion traces are invisible, do not promise downstream import or alert success.
If previous temporary hierarchy cleanup tasks failed but the owner is still readable, classify the environment as reusable with a cleanup caveat instead of pretending the root inventory changed.

Validation scenarios

1. Unknown environment bootstrap

Start with idmp-cli element elements list --params and idmp-cli element elements path --params. The goal is to prove the current visible root before anything else.

2. Model-ready but ingestion-unknown environment

Use idmp-cli attr-template elements attributes --params to prove template readiness, then idmp-cli datasource connections list to confirm ingestion visibility separately.

3. Root list is empty

Stop after idmp-cli element elements list --params returns nothing useful. The next step is auth or permission diagnosis, not a guessed bootstrap answer.

4. Template mismatch on the chosen root

Use idmp-cli template elements list --params and idmp-cli element elements sub-templates --params to show the mismatch. Switch owners instead of inventing template compatibility.

5. Post-write reread

If a previous operator already created temporary objects, reread with idmp-cli data first-level-elements list and idmp-cli data records list before claiming the environment is reusable. If the objects are still readable only because an async delete task previously failed, record that as a backend cleanup caveat instead of retrying destructive cleanup here.

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