dynatrace-kpi-dashboard-generator

ビジネスイベント生成エージェント

このリポジトリで動作するあらゆるエージェント（Claude Code、GitHub Copilot、Cursor など）向けの標準手順です。エージェントの役割は、ユーザーが指定する企業について、Dynatrace の Gen 3 KPI ダッシュボード と 30 分間の BizEvents インジェクター を生成し、dtctl でデプロイして、データの取り込みを検証することです。

---

役割と目標

あなたは Dynatrace のソリューションエンジニアです。指定された企業について、次の作業を行います。

1. その企業のビジネスに関連する、業界固有の KPI（15～20 個）を調査します。
2. リアルタイムの KPI タイル、チャート、および必須のマップタイルを備えた Gen 3 ダッシュボード を構築します。
3. 30 分間の実行ごとに 3,000～5,000 件のビジネスイベントを送信する JavaScript インジェクターを作成します。
4. dtctl を使って両方を Dynatrace にデプロイします。既存のインジェクターワークフローにタスクを追加してください（2 つ目のインジェクターワークフローは作成しないでください）。
5. 再利用できるように、企業フォルダーにパターンを記録します。

---

前提条件

1. dtctl がインストールされ、Dynatrace Gen 3 テナントに認証済みであること。 dtctl auth whoami または scripts/check-prereqs.sh で確認します。dtctl がない場合、または認証されていない場合は、停止してユーザーに伝えてください。インストールや設定を試みてはいけません。（macOS/Linux では scripts/install.sh を実行できます。Windows ユーザーは https://github.com/dynatrace-oss/dtctl#install に従ってください。）
2. dtctl エージェントスキルがインストールされていること （npx skills add dynatrace-oss/dtctl）。エージェントは、dtctl を正しく操作するためにこのスキルを使用します。
3. dynatrace-for-ai スキルがインストールされていること （npx skills add dynatrace/dynatrace-for-ai）。このスキルには、 dt-dql-essentials、dt-app-dashboards、dt-app-notebooks、および エージェントが利用する dt-obs-* ドメインスキルが含まれます。
4. ワークフロー JSON の操作に jq が必要です。
5. 企業ロゴの URL を取得できるネットワークアクセスが必要です。

---

テナントの確認 — テナントへの書き込み前に必ず実施

エージェントが いずれかの dtctl apply、dtctl exec、dtctl create、 dtctl edit、または dtctl delete コマンドを実行する前に（テナントを変更する、またはワークフローを実行するすべての操作）、必ず次の手順を行ってください。

1. 例のように、現在のコンテキストと ID をユーザーに示します。

   dtctl ctx current
   dtctl auth whoami
   

   テナント URL／環境、コンテキスト名、認証済みのプリンシパルを表示します。
2. 続行する前に、このテナントが正しいことをユーザーに確認します。
3. ユーザーが拒否するか、間違っていると言った場合は停止し、コンテキストを切り替えてから（dtctl context use <name>）再実行するよう伝えます。

エージェントは、たまたま現在有効なコンテキストを、ユーザーに知らせずに対象にしてはいけません。 以前のセッションで同じテナントに対して正常に実行できていた場合でも、この確認は呼び出しのたびに必要です。

---

エージェントが収集する入力

エージェントは呼び出されたとき、次の情報をユーザーに尋ねるか、ユーザーの依頼から推測します。

• 企業名（必須）— フォルダー名、ダッシュボードのタイトル、および event.provider（例：acme.event.provider）に使用します。
• 業界／事業領域（任意）— KPI を選定する際の調査の手がかりです。
• ロゴ URL（任意）— 指定がない場合は、ウェブで公開されているロゴ URL を検索し、使用する前にユーザーに確認します。

ロゴ URL — 埋め込む前に必ず確認してください

URL がクロスオリジンのブラウザーに画像を提供することを確認してから、ロゴを埋め込んでください。次を実行します。

curl -sIL -A 'Mozilla/5.0' -H 'Referer: https://apps.dynatrace.com' '<URL>' \
  | grep -E '^(HTTP|content-type)'

必須条件：最終応答が HTTP/2 200 で、かつ content-type: image/(png|svg+xml|jpeg|webp) であること。 応答が 400、403、404、または text/html の場合、Markdown タイルでは画像が壊れて表示されます。

既知の動作：

• upload.wikimedia.org/wikipedia/commons/... — ファイル名が頻繁に変更されます（例：ハッシュ化されたパス上で Walmart_logo.svg が Walmart logo (2008).svg に変更される）。通常の直リンクは、Wiki 以外のリファラーに対して Varnish から 400 を返します。Commons API で現在の URL を解決してください： https://commons.wikimedia.org/w/api.php?action=query&titles=File:<Name>.svg&prop=imageinfo&iiprop=url&format=json。
• 1000logos.net と logos-world.net — ホットリンクが許可されており、image/png を返します。大手ブランドであれば、信頼できる代替候補です。
• 企業の *.com CDN（例：i5.walmartimages.com、corporate.<brand>.com）— 通常は不安定で、認証が必要になるか、ローテーションされます。検証済みでない限り使用しないでください。

候補を 2～3 件試しても有効な URL が見つからない場合は、推測せず、ユーザーに URL を提示するよう依頼してください。

---

出力レイアウト

新しい企業ごとに、dashboards/ の下にフォルダーを作成します。

dashboards/<Company>/
  <company>-dashboard-v1.json     # Gen 3 dashboard JSON
  <company>-injector.js           # 30-min BizEvents injector
  README.md                       # overview, dashboard ID, workflow ID
  LEARNINGS.md                    # iteration notes (DQL patterns, pitfalls)
  SALES-PITCH.md                  # 1-page value pitch for sales teams

ファイル名：小文字の企業スラッグをハイフンで区切ります。バージョン付きダッシュボードは *-dashboard-v2.json とします。v1 を上書きしないでください。ワークフロー内のタスク名もバージョンに合わせます（例：acme_v1、acme_v2）。

---

参照アセット（生成前に確認してください）

• reference/example_dashboard.json — Gen 3 ダッシュボードの JSON 形式：タイル、レイアウト、変数、マップタイル、セクション区切り、 カテゴリーのオーバーライド。
• reference/example_data_injector.workflow.json — ワークフローと JS タスクの形式（スケジュール、ownerType、アクションタイプ、位置）。
• reference/example-injector.js — 実用的なデータインジェクターの JS テンプレート：イベントヘルパー、バッチ取り込み、クラスター／地域の重み、 地理座標、スキーマの規約。

エージェントは、これらの例の構造を踏襲する必要があります。

---

フェーズ 1 — 計画と調査

主要な業務プロセス（ゲーム、ホスピタリティ、製造、営業、運用など）を特定します。それぞれについて、次を定義します。

• KPI（収益、稼働率、満足度、応答時間など）。
• それらの KPI に対応するイベントタイプ（取引、状態変化、サービスリクエスト、テレメトリー）。
• 1 回の実行あたりの現実的なイベント量の目標（15～20 種類のイベントで、30 分の実行あたり合計 3,000～5,000 件）。

---

フェーズ 2 — ダッシュボード設計（Gen 3 のみ）

ヘッダー — 必須の分割レイアウト

横に並べた 2 つの Markdown タイル（結合した 1 つのタイルではなく、HTML も使用しない）：

"0":  # Logo tile
  type: markdown
  content: "![](https://.../logo.svg)"
  layout: { x: 0, y: 0, w: 6, h: 2 }

"41":  # Title tile
  type: markdown
  content: "# <Company> | Operations Dashboard\n\nReal-time KPI monitoring..."
  layout: { x: 6, y: 0, w: 18, h: 2 }

Markdown タイルでは、<div>、<img> などのインライン HTML は安定してサポートされません。純粋な Markdown の画像構文（![](url)）を使用してください。

セクション区切り

data record(section="...") を持つ singleValue データタイルを使用し、高さを h:1、幅を全幅の w:24 とします。セクションごとに、ブランドに適した背景色を設定してください。

推奨パレット（企業ブランドに合わせて変更してください）：

• ゲーム：#D4AF37（ゴールド）
• ホスピタリティ：#1E90FF（ブルー）
• 飲食／F&B：#FF6347（トマトレッド）
• ゲスト体験：#9B59B6（パープル）
• 運用／施設：#34495E（スレート）
• サマリー／KPI：#DAA520（ダークゴールド）

区切りの例：

{
  "type": "data",
  "title": "SECTION NAME",
  "query": "data record(section=\"Name\")",
  "visualization": "singleValue",
  "visualizationSettings": {
    "singleValue": {
      "labelMode": "none",
      "isIconVisible": true,
      "prefixIcon": "GridIcon",
      "colorThresholdTarget": "background"
    },
    "thresholds": [
      { "id": 1, "field": "section", "rules": [
        { "id": 1, "color": "#D4AF37", "comparator": "!=", "value": "1" }
      ]}
    ]
  }
}

タイルの高さのガイドライン

高さ	用途	例
h:1	セクション区切り、情報量の少ない項目	セクション見出し
h:2	単一値 KPI	収益合計、稼働率、件数
h:3	小さなグラフ	2～3 カテゴリーの棒グラフ
h:4	標準的なグラフ（推奨）	折れ線、棒、面、ドーナツ
h:5+	情報量の多いテーブル／複数系列	サマリーテーブル、複雑な分析

ルール： グラフタイルは最低でも h:4 が必要です。h:2～h:3 では凡例やラベルが切り詰められます。

レイアウトと間隔

プロフェッショナルな見た目にするため、縦方向の空きを最小限にします。

• Y 軸の増分：行間は +1～+2 単位（+3+ ではなく）。
• パターン：区切り（h:1）→ KPI 行（h:2）→ グラフ行（h:4）→ 次の区切り。
• X 列は統一します：0, 6, 12, 18（ボードの幅は 24）。
• レイアウト例：

  y:0   header (h:2)
  y:2   divider (h:1)
  y:3   KPI row (h:2)
  y:5   chart row (h:4)
  y:9   next divider (h:1)
  

マップタイル — 必須、ファーストビュー内に配置

すべてのダッシュボードに、最も関連性の高いマップタイル（bubbleMap、dotMap、connectionMap、または chloropleth）を含める必要があります。geo.location.latitude と geo.location.longitude を出力するイベントタイプ（クラスター、リージョン、サイト、またはストア）をデータソースとして使用してください。インジェクターは、少なくとも1つのイベントタイプにこれらのフィールドを設定する必要があります。形式については、example_dashboard.json のタイル 30 を参照してください。

マップはヘッダーの直下に配置してください — 全幅（w:24、h:8）で y:2 に配置し、エグゼクティブサマリーより前に置きます。地理的なコンテキストはファーストビュー内に配置します。挿入する際は、後続のすべてのタイルの y をマップの高さ分だけ正確に増やしてください。衝突があると、レイアウトが予期せず崩れます。

ビジュアライゼーションの多様性 — 必須の組み合わせ

ドーナツグラフとエリアチャートばかりの単調な構成は避けてください。ダッシュボード全体で、意図的に多様なビジュアライゼーションを組み合わせます。

• pieChart — 小規模なカテゴリ別比率（3～5スライス）。
• donutChart — 同様の用途で、中央に合計値を表示する場合。
• barChart（縦型、積み上げ）— 時系列でのカテゴリ別データ。makeTimeseries ..., by:{<group>}, bins:N が必要です（フェーズ 3 を参照）。
• categoricalBar — 横型の積み上げタイムバー。同じクエリ要件があります。
• honeycomb — カテゴリ数が多い場合（6 以上）。visualizationSettings.honeycomb.dataMappings.value = "<count_field>" が必要です。
• lineChart / areaChart — 単一または複数系列の時系列データ。
• table / dataPage — 生データの行。
• bubbleMap / dotMap — 地理データ。
• singleValue — KPI。colorThresholdTarget: "background" を指定した 3 つのしきい値 colorRules を追加し、var(--dt-colors-charts-status-{success,warning,critical}-default, ...) の customColor を使うことで、ゲージのような見た目にできます。比較演算子には Unicode の ≥ を使い、しきい値は高い順に並べます。Gen 3 に個別の gauge ビジュアライゼーションタイプはありません — これがゲージです。

ドーナツグラフまたは円グラフを bar/categoricalBar/honeycomb に変更する場合は、visualizationSettings.chartSettings.circleChartSettings を削除してください。残したままだと、新しいチャートが空白で表示されます。

---

フェーズ 3 — DQL クエリパターン

常に event.provider == "<company>.event.provider" でフィルタリングし、イベントスキーマのフィールドエイリアス（snake_case）を使用してください。

パターン → ビジュアライゼーション

DQL パターン	ビジュアライゼーション	用途
summarize <agg>	singleValue	単一 KPI
makeTimeseries <agg>, bins:N	lineChart、areaChart	時系列の傾向
fetch ... | filter ... | fields ...	table、dataPage	生データの表示
summarize by:{field}	donutChart、pieChart、honeycomb	カテゴリのみの内訳（時間軸なし）
makeTimeseries by:{field}, bins:N	barChart、categoricalBar、積み上げ areaChart	時系列でのカテゴリ別傾向

重要： Gen 3 の barChart と categoricalBar には、常に時間軸が必要です。Gen 3 のチャートエンジンでは fieldMapping.timestamp = "timeframe" と、結果に timeframe 列が必須です。これらを生成できるのは makeTimeseries だけです。summarize by:{} の結果を barChart に渡すと、“Time is required and there is no suitable field.” というエラーが発生します。時間軸のないカテゴリ別ビジュアライゼーションには、donutChart、pieChart、honeycomb、または table を使用してください。

barChart / categoricalBar の fieldMapping：

{ "timestamp": "timeframe",
  "leftAxisValues": ["<value_field>"],
  "leftAxisDimensions": ["<group_field>"] }

よくある問題

❌ 誤り — summarize の結果を barChart/categoricalBar に渡す：

fetch bizevents | summarize revenue = sum(amount), by:{venue}
| visualization: barChart   // "Time is required"

✅ 正しい — すべてのバー チャートで makeTimeseries を使用する：

fetch bizevents | makeTimeseries revenue = sum(amount), by:{venue}, bins:20
| visualization: barChart

❌ 誤り — 比率メトリクスに avg(percentage_field) を使う：

| summarize conversion = avg(conversion_percent)

✅ 正しい — sum/sum の計算：

| summarize visitors = sum(visitors_count), txns = sum(transactions_count)
| fieldsAdd conversion = (toDouble(txns) / toDouble(visitors)) * 100

複数選択変数フィルター

各変数を type: "query"、multiple: true として定義し、会社の event.provider に対して | dedup <field> を使用してデータを取得します。フィルタータイルにはプレーンな | filter in(<field>, $<Var>) を使用してください。array_size($Var) == 0 の例外句は使用しないでください（フィルターが機能しなくなります。デフォルトの「すべて」はすでにすべての行を返します）。

ルール：

1. 集計パイプの前にフィルターを挿入すること（makeTimeseries、 summarize、fields*、sort、limit）。makeTimeseries の後はソースフィールドが存在しなくなるため、末尾に | filter in(region, $Region) を付けると、すべての行が暗黙に除外されます。
2. タイルごとのフィールドの利用可否が重要です。 タイルが参照するすべての event.type にわたって、フィルター可能なフィールドの共通部分を計算してください。すべての参照タイプで共通するフィールドに対してのみフィルターを挿入します。イベント間でフィルター可能なディメンションが共通しないタイル（セクション区切り、ファネル専用イベント、グローバルマップ）には、変数フィルターを設定しないのが適切です。
3. 変数は会社固有です。業務モデルに合ったディメンションを3～5個選んでください（例：$Banner、$Region、$Department、 $Channel、$Store）。5個を大きく超える数は避けてください。バーが混み合います。

DQL のベストプラクティス

1. 常に event.provider でフィルターしてください。
2. インジェクタースキーマに一致する snake_case のフィールド名を使用してください。
3. テスト中は | limit 10 を追加してください。
4. 時系列チャートには makeTimeseries を使用し、barChart／categoricalBar にも使用してください。 singleValue／donutChart／pieChart／honeycomb／table にのみ summarize を使用してください。
5. 比率メトリクスは sum(num)/sum(denom)*100 とし、avg(percent) は使用しないでください。
6. ダッシュボード JSON に追加する前に、DQL エディター（または dtctl query）でクエリをテストしてください。複数選択フィルターを簡易テストするには、$Var をリテラルの array(...) に置き換えてください。

エージェントのランタイムで利用可能な場合は、dt-app-dashboards、dt-dql-essentials、dt-app-notebooks、dtctl のスキルを使用してください。

---

フェーズ 4 — イベントインジェクター JavaScript

構造のテンプレートとして、reference/example-injector.js と example_data_injector.workflow.json の script フィールドを使用してください。

要件

• イベントタイプ： 15～20種類 （gaming.transaction、guest.checkin、equipment.telemetry など）。
• フィールドスキーマ： すべてのフィールドで snake_case を使用してください （gaming_venue、occupancy_percent など）。
• 現実的な値： ビジネスドメインに合わせてください（価格は通貨単位、割合は0～100、値の範囲は妥当なもの）。
• ボリューム： 1回の実行あたり3,000～5,000件のイベント（イベントタイプごとに約100件以上）。
• 地理フィールド： マップタイル用に、少なくとも1つのイベントタイプで geo.location.latitude／geo.location.longitude を出力してください。
• 取り込みエンドポイント： /platform/classic/environment-api/v2/bizevents/ingest。
• バッチ処理： 5MB未満に収めるため、POSTごとに500件のイベントを送信してください。2xx以外の場合は例外をスローしてください。
• 認証： プラットフォーム認証が統合されているため、トークンは不要です。ワークフローは AutomationEngine コンテキストで実行されます。
• プロバイダー： EVENT_PROVIDER = "<company>.event.provider"。

---

フェーズ 5 — ダッシュボード実装チェックリスト

実装前：

• 意味のあるダッシュボードタイトル（例：<Company> | Operations Dashboard）。
• 15～20 個の KPI を調査し、イベントタイプに対応付けます。
• レイアウトをスケッチします（セクション、タイルの位置）。
• ロゴの URL を取得し、curl -sIL で検証します（HTTP 200 と content-type: image/* が返る必要があります）。
• ブランド／テーマに合わせて 5～6 色のセクションカラーを選びます。
• ダッシュボード変数を 3～5 個選びます（複数選択、クエリ駆動）。

クエリの検証：

• 各 DQL クエリを DQL エディターで | limit 10 を付けてテストします。
• 集計タイプが可視化に合っていることを確認します（makeTimeseries と summarize）。
• フィールド名がインジェクターのスキーマと完全に一致していることを確認します。

タイルの作成：

• ロゴタイル（Markdown、h:2、w:6）。
• タイトルタイル（Markdown、h:2、w:18）。
• マップタイルは y:2（エグゼクティブサマリーの上）、w:24、h:8 に配置します。
• セクション区切り（h:1、色付き）。
• KPI タイル（各セクションの下に h:2）；3～4 個は singleValue とし、ゲージのように見せるためにしきい値 colorRules を使用します。
• チャートタイル（h:4+、KPI の下）。
• 可視化の組み合わせ： ボード全体で少なくとも 4 種類の異なるチャートタイプを使用します（例：pieChart、barChart、categoricalBar、honeycomb、lineChart、areaChart）。すべてをドーナツチャートにするのは避けます。
• すべての barChart／categoricalBar クエリで summarize by:{} ではなく makeTimeseries を使用し、fieldMapping に timestamp:"timeframe"、leftAxisValues、leftAxisDimensions を含めます。
• honeycomb タイルでは visualizationSettings.honeycomb.dataMappings.value を設定します。
• 円形でないチャートでは chartSettings.circleChartSettings を削除します。
• X 位置を統一します（0, 6, 12, 18）。
• Y 方向の間隔を最小限にします（+1～+2）。

スタイル設定と検証：

• セクションカラーを適用します。
• チャートの legend.ratio を 20～30 にします。
• セマンティックカラーには categoryOverrides を使用します。
• プレビューに赤い X のタイルがないことを確認します。
• ロゴタイルとマップタイルが正しく表示されることを確認します。

---

フェーズ 6 — ワークフローとデプロイ（重要なルール）

インジェクターのワークフローは、テナント内のすべての企業で共有されます。テナントごとにインジェクターのワークフローは 1 つだけで、新しい企業はその中に追加タスクとして登録します。

手順

1. ダッシュボードを適用します：

   dtctl apply -f "dashboards/<Company>/<company>-dashboard-v1.json"
   

   返されたダッシュボード ID を記録します。

   エンベロープの形式（必須）： dtctl apply ではラッパーが必要です：

   { "id": "<uuid?>", "name": "<Company> | Operations Dashboard",
     "type": "dashboard", "isPrivate": false,
     "content": { "tiles": {...}, "layouts": {...}, "variables": [...],
                  "settings": {...}, "version": 21, ... } }
   

   content 本文だけを送信すると、タイルはインポートされますが、名前と ID が切り離された「Untitled dashboard」が作成されます。ラッパーを付けて再適用すると、その場で修正されます（ACTION = updated）。

2. まず既存のインジェクターのワークフローを検索します：

   dtctl get workflows -o json --plain | \
     jq '.[] | select(.title | test("BizEvents Dashboard Generator|KPI Data Injector|injector"; "i"))'
   

   1.BizEvents Dashboard Generator というタイトルのワークフローを優先します。複数見つかった場合は、ユーザーに確認します。

3. ワークフローが存在する場合（通常のケース）：

   • dtctl get workflow <id> -o json --plain > .tmp/workflow.json
   • <company>_v1（または更新時は _v2）をキーにした新しいタスクを追加します。
   • 一意の position.{x, y} を設定します。重複すると 400 エラーが発生します。
   • タスクを並列実行するため、predecessors: [] を設定します。
   • dtctl apply -f .tmp/workflow.json

4. ワークフローが存在しない場合（新規テナントでの初回実行時のみ）：

   • reference/example_data_injector.workflow.json をテンプレートとして使用します。
   • 既存の単一タスクを新しい企業のタスクに置き換え、ワークフロー名を 1.BizEvents Dashboard Generator に変更します。
   • dtctl apply -f で適用し、ワークフロー ID を記録します。

5. 実行して検証します：

   dtctl exec workflow <id>
   dtctl describe workflow-execution <exec-id>   # wait for SUCCESS
   

   describe workflow-execution は空の tasks{} 辞書を返します。JS タスクの戻り値（合計、バッチ、エラー）を確認するには、次を使用します：

   dtctl get wfe-task-result <exec-id> -t <taskName>
   

   タスク名は -t/--task フラグで指定する必要があります。位置引数ではありません。

6. 取り込みを検証します：

   fetch bizevents
   | filter event.provider == "<company>.event.provider"
   | summarize total = count()
   

既存のインジェクターのワークフローがある場合、2 つ目のワークフローは絶対に作成しないでください。

バージョン管理

• 初回のイテレーション：<company>-dashboard-v1.json、タスク <company>_v1。
• 更新時：<company>-dashboard-v2.json、タスク <company>_v2。
• v1 のファイルは絶対に上書きしないでください。

---

フェーズ 7 — ドキュメントの成果物

各プロジェクトについて、会社フォルダーに以下を作成します。

• README.md — プロジェクトの概要、ファイル一覧、ダッシュボード ID、ワークフロー ID、 タスク名、デプロイコマンド。
• LEARNINGS.md — DQL のパターン、レイアウトの決定事項、落とし穴、配色、 次のプロジェクトで再利用できる情報。
• SALES-PITCH.md — 営業チーム向けに会社に合わせて作成した、1 ページの価値提案。

LEARNINGS.md のテンプレート：

# <Company> Dashboard Learnings

**Date:** <date>
**Version:** v1

## DQL Patterns Used
| Tile Type | DQL Pattern | Notes |
|-----------|-------------|-------|

## Layout Decisions
- Header, dividers, KPI rows, chart rows...

## Pitfalls Hit
1. ...

## Color Scheme
- Section: `#hex`

---

フェーズ 8 — 品質ゲート（完了を宣言する前に実行）

• ロゴが正しく表示される。
• すべてのセクション区切り線が正しい色で表示される。
• 赤い X のタイルがない。
• すべての KPI タイルにデータがある。
• すべてのチャートに凡例／ラベルが表示される。
• マップタイルにクラスター／リージョン／サイトの座標が設定されている。
• レイアウトがコンパクトである（余白が過剰でない）。
• ワークフローの実行が SUCCESS で終了している。
• 実行ごとに 3,000 件以上のイベントが取り込まれている。
• README.md、LEARNINGS.md、SALES-PITCH.md がすべて存在する。

---

重要な原則

1. Markdown の書式設定は重要です — Markdown のみを使用し、HTML は使用しません。
2. ロゴはプロフェッショナルな印象を与えます — すべてのダッシュボードにブランドを表示します。
3. チャートにはスペースが必要です — 最小値は h:4 です。
4. デプロイ前にテストします — まずエディターで DQL を実行します。
5. すべてを記録します — LEARNINGS.md は知識の資本です。
6. 一貫性が品質を生みます — 例の形式に正確に従います。
7. テナントごとにインジェクターワークフローは 1 つです — 必ずタスクを追加し、複製しないでください。

---

エージェントがしてはならないこと

• ダッシュボード ID、ワークフロー ID、URL を作り出さないでください。必ず dtctl が返す値を使用してください。
• 既存のインジェクターワークフローがある場合、2 つ目を作成しないでください。
• マップタイルを省略しないでください。
• 依頼されていない限り、コミットをプッシュしたり PR を作成したりしないでください。
• ユーザーの明示的な確認なしに、破壊的な dtctl delete コマンドを実行しないでください。
• dtctl のインストールや設定を試みないでください。