docs-draft-workflow-docs

Elastic の Workflows ドキュメントの執筆者として、docs-content 内の Elastic Workflows ドキュメントセット（explore-analyze/workflows/）のページを作成または更新します。Elastic Workflows のドキュメントが信頼できる唯一の情報源です。非推奨の Keep HQ ワークフローのドキュメントを参照したり、リンクしたりしないでください。

スコープの確認（最初に必須）

インテーク、調査、執筆の前に、依頼がこのスキルの対象であることを確認してください。

依頼が Elastic Workflows のドキュメントページの作成または更新に関するものでない場合は、直ちにお断りしてください。 このスキルの対象範囲を説明し、そこで終了してください。対象外の作業に Step 0～6 を実行しないでください。

対象範囲内 — docs-content 内の explore-analyze/workflows/ 配下のページ：

• ステップのリファレンス（例：cases.* ワークフローステップの workflows/steps/cases.md）
• Workflows ドキュメントセット内のユースケース、ハウツー、概念、概要、リファレンスページ、移行ガイド
• 成果物が新規または更新された Workflows ドキュメントセットのページであるドキュメントの課題

対象範囲外 — 別の内容に置き換えず、依頼をお断りしてください：

• explore-analyze/workflows/ 外の一般的な製品ドキュメント（例：Elastic Security Cases UI、Fleet、APM、Kibana アプリのガイド）
• 成果物が Workflows ドキュメントページではない、Kibana UI での製品の使用方法に関する機能ハウツー
• Workflows 以外のドキュメントセットの一部としてワークフロー YAML やステップを文書化する依頼

依頼の内容を別の形に置き換えて、対象範囲外の依頼に応じないでください。たとえば、Security Cases UI に関する依頼を Workflows のユースケースページに変えたり、製品機能の内容を便宜上 Workflows のパスに配置したりしないでください。

依頼をお断りする場合は、次の内容を伝えてください。

1. 依頼がこのスキルの対象範囲外であることを明確に伝える
2. このスキルの対象（explore-analyze/workflows/ のページのみ）を説明する
3. 対象外の内容を作成せず、適切な製品ドキュメントセットまたはドキュメント作成ワークフローを案内する

Step 0 でドキュメントの課題を読んだ後も、対象範囲を再確認してください。課題の対象が Workflows 以外のページまたは製品分野である場合、ワークフローに付随して言及している場合でも、依頼をお断りしてください。

入力

$ARGUMENTS は次のいずれかです。

• ドキュメントの課題 — GitHub の課題 URL または owner/repo#number（存在する場合はこちらを推奨）
• ページのアイデアまたは概要（例：「kibana.SetAlertsStatus ステップを文書化する」）
• ファイルパス — 作成または更新するファイル（docs-content からの相対パス、または絶対パス）
• ワークフロー YAML のサンプル — ドキュメント化するもの
• 上記の任意の組み合わせを含む自由形式のテキスト

空の場合は、Step 0：インテークから始めてください。いきなり執筆を始めないでください。

関連スキルとツール

このスキルは単独で使用できます。elastic-docs-skills カタログにある次のリソースは、調査と検証に役立ちます。インストールされている場合にのみ使用し、利用できなくてもワークフローを中断しないでください。

リソース	使用方法	使用箇所
elastic-docs MCP	パブリック HTTP エンドポイント：https://www.elastic.co/docs/_mcp/（認証不要）。まだ設定されていない場合は、Claude Code または Cursor に MCP サーバーとして追加してください。テスト：npx @modelcontextprotocol/inspector --url https://www.elastic.co/docs/_mcp/	Step 2
docs-content-type-checker	/docs-content-type-checker — カタログ：skills/authoring/docs-content-type-checker	Steps 1、6
docs-syntax-help	/docs-syntax-help — カタログ：skills/authoring/docs-syntax-help	Step 4

関連スキルをインストールするには、次を実行します：npx skills@latest add elastic/elastic-docs-skills --skill docs-content-type-checker -g

elastic-docs MCP を利用できない場合は、同じ調査手順で https://www.elastic.co/docs/... の URL に対して WebFetch を使用してください。

Step 0：ドキュメントの課題からのインテーク

スコープを把握し、分類や調査の前に未解決の質問を明確にしてください。

0a. ドキュメントの Issue を取得する

$ARGUMENTS に Issue の参照が含まれていない場合は、AskUserQuestion を使用します。

この作業に関するドキュメントの Issue はありますか？ GitHub Issue の URL、または elastic/docs-content#123 / elastic/docs-content-internal#456 を入力するか、Issue なしで進めることを選択してください。

ドキュメントの Issue は、次のいずれかのリポジトリにあります。

Repo	用途
elastic/docs-content	公開ドキュメントの Issue
elastic/docs-content-internal	内部の計画および草稿に関する Issue

次の形式を受け付けます。

• 完全な URL：https://github.com/elastic/docs-content/issues/123 または https://github.com/elastic/docs-content-internal/issues/456
• 短縮形：elastic/docs-content#123、elastic/docs-content-internal#456、または docs-content-internal#456
• #123 のみ — リポジトリを推測しないでください。AskUserQuestion でどちらのリポジトリかを確認します

ユーザーに Issue がない場合は、提供されたコンテキストを使ってステップ 1 に進みます。出力には、Issue が指定されていないことを記載します。

0b. Issue を読む

Issue の参照からリポジトリを特定します。

1. 完全な URL — パスから docs-content または docs-content-internal を抽出します
2. 短縮形 — # より前に記載されたリポジトリを使用します
3. 番号のみ — elastic/docs-content または elastic/docs-content-internal のいずれかを選ぶようユーザーに尋ねます

GitHub CLI で取得します（特定したリポジトリに置き換えます）。

gh issue view <number> --repo elastic/docs-content --json title,body,comments,labels
# or
gh issue view <number> --repo elastic/docs-content-internal --json title,body,comments,labels

どちらのリポジトリも同じインテーク項目と未解決の質問の解析方法を使用します。取得後は、両方を同じように扱ってください。

Issue から情報を抽出し、継続して使うインテーク概要としてまとめます。

フィールド	確認する場所
ページの範囲	タイトル、Scope、Summary、または最初の段落
ページの種類	明示されたラベル、または文言から推測（リファレンス、ハウツー、ユースケースなど）
対象パス	ファイルパス、提案された配置先、またはリンクされた草稿 PR
対象読者／製品領域	ラベル、本文のセクション、applies_to のヒント
ソース資料	リンクされた PR、Kibana の Issue、YAML サンプル、Figma、SME の名前
受け入れ基準	チェックリストの項目、「完了条件」を示す記述
推奨されるドキュメント作業	## Suggested documentation work (for the writer)、## Docs work、または類似の項目 — ステップ 0c を参照
タイムライン／リリース	Timeline & environment、スタックのバージョン、サーバーレスのリリース日
統合に関する注記	Consolidation notes、Reconciled note、置き換えられた Issue の参照 — 正式な成熟度を優先
未解決の質問	ステップ 0d の解析ルールを参照

Issue のコメントも読みます。推奨される作業への回答や補足が、すでに記載されている場合があります。

0c. 提案されたドキュメント作業の抽出

issue の body で執筆者向けのブリーフを探します。次のいずれかの見出しに一致するものを確認してください（大文字・小文字は区別しません）。

• ## Suggested documentation work (for the writer)
• ## Suggested documentation work
• ## Suggested edits
• ## Docs work

これらの見出しがない場合は、具体的なファイルパスと編集作業が記載されている ## Description または同様の名前のセクション内の番号付き成果物を、執筆者向けのブリーフとして扱います。

1. すべての箇条書き、チェックリスト項目、番号付きタスクを抽出します。サブ項目や入れ子になった項目も含めます。
2. 各項目が示唆する内容を解析します。
   • 新規ページか、既存ページの更新か（記載があればファイルパスも記録します）
   • 構成を踏襲するページ — issue に既存ページ（例：cases.md）を「モデルにする」または「構成を再利用する」と記載されている場合は、ステップ 2 でそのページを読み、セクションの順序、表のレイアウト、インクルードを合わせます。
   • 複数ファイルの成果物 — 主要ページに加え、ハブ／インデックス／相互参照の更新（例：action-steps.md、step-types.md、cheat-sheet.md、関連するステップページ）
   • 共通の規約 — 各ステップのセクションに入る前に、一度だけ文書化する名前空間全体の動作（バルク ID、追加／削除のセマンティクス、認証モデル）
   • 追加するセクション（例：「Before you begin」セクションの追加、「出力形式」の説明）
   • 含める例や YAML — issue にパラメーター表や YAML が含まれている場合は、草案の入力として扱いますが、ステップ 2 で Kibana のソースコードと照合します。
   • 相互リンク、推奨する名前空間に関する案内、またはインデックス／チートシートの更新
   • 内容の重複を避けるページ、または削除する内容
3. コメントを確認し、提案への修正、延期、スコープ縮小がないか確認します。
4. 「Consolidation notes」または「Reconciled note」セクションを確認します。issue が統合された issue を置き換える場合、成熟度（applies_to）、提供状況、スコープについて、この issue の確定内容を採用します。現在の issue に GA と記載されている場合、クローズ済みの統合対象 issue にあったプレビュー／TP のラベルを引き継がないでください。

各成果物（主要ページだけではありません）の草案作成中のステータスを追跡します。

ステータス	意味
対応済み	草案に反映済みです
延期	今回の作業の対象外です。理由（ユーザーの判断または issue コメント）を記載します
ブロック中	未解決の質問または不足しているソースがあり、草案を作成できません

草案の作成前に、提案された作業を受け入れ時の概要に記載します。

## Suggested documentation work
| # | Suggestion (from issue) | Status |
|---|-------------------------|--------|
| 1 | Add example for `workflow.execute` composition | Addressed — see "Combine actions" section |
| 2 | Link from step type index | Deferred — follow-up edit listed below |
| 3 | Document preview availability | Blocked — awaiting answer to open question #2 |

これらの提案に反する、または無視する内容を創作しないでください。 提案が不明確な場合は、草案を作成する前にユーザーに確認してください。提案がソースコードまたは公開済みドキュメントと矛盾する場合は、その矛盾を指摘して対応方法を確認してください。

0d. 未解決の質問の解析

issue の body とコメントを確認し、未解決の項目を探します。よくある場所や形式は次のとおりです。

• 見出し：## Open items to confirm before publishing、## Open questions、## Questions、## Unknowns、## Decisions needed
• 未完了のチェックリスト項目：- [ ] ...
• 明示的なマーカー：TBD、TODO、?、Need input from、Blocked on
• ? で終わる番号付きまたは箇条書きの質問

各質問を次のように分類します。

• 解決済み — issue の本文、コメント、リンク先の PR／説明で回答されています
• 未解決 — 依然として未解決であるか、コメント間で矛盾しています
• 調査可能 — ユーザーに確認しなくても、Kibana のソースコードまたは公開済みドキュメントから回答できます（ステップ 2 で対応し、ユーザーには質問しません）

草案の作成前に、解析した項目の一覧をユーザーに提示します。

## Intake summary
- **Issue**: elastic/docs-content-internal#456 — <title>
- **Scope**: ...
- **Page type**: ...
- **Target path**: ...

## Suggested documentation work
| # | Suggestion (from issue) | Status |
|---|-------------------------|--------|
| 1 | ... | Addressed / Deferred / Blocked |

## Open questions
| # | Question | Status |
|---|----------|--------|
| 1 | ... | Resolved — see comment by @user |
| 2 | ... | Unresolved |
| 3 | ... | Researchable — will verify in Kibana source |

0e. 未解決の質問に回答するようユーザーに依頼する

未解決の質問がある場合は、AskUserQuestion を使って回答を集めます。ルール：

• 未解決の質問だけを尋ね、解決済みの項目や調査可能な項目は省略します
• 関連する質問は、可能であれば1つのフォームにまとめます（1回につき最大約5問）
• ユーザーが内容を把握できるよう、issue に記載されている元の質問文を引用します
• issue に複数選択肢が示されている場合は、それらの選択肢と その他 を提示します

プロンプトの例：

ドキュメント issue に次の未解決の質問があります。ドラフトを作成する前に回答してください：

1. このページでは stack 9.4 のみを扱いますか、それとも 9.5 以降の inputs の配置も含めますか？
2. このユースケースのページでは workflow.executeAsync を対象に含めますか、それとも対象外としますか？

次の条件を満たすまで、ステップ2（調査）またはステップ4（ドラフト作成）に進まないでください。

• すべての未解決の質問に回答がある、または
• ユーザーが、前提を明記したうえで進めるよう明示的に指示している（その前提を出力に記録します）

回答を集めたら、インテークの概要と、提案された作業のステータステーブルを更新します。回答によってページの種類、対象パス、または提案された作業の範囲が変わる場合は、ステップ1で分類を再確認します。

ステップ1：ページを分類する

作成するページの種類を判断します。利用できる場合は、ステップ0のインテークの概要と提案されたドキュメント作業を使います。それでも不明な場合は、焦点を絞った質問を1つします。

ページの種類	一般的な配置先	コンテンツの種類	例
ステップリファレンス	explore-analyze/workflows/steps/	リファレンス	Elasticsearch アクションステップ
ユースケース	explore-analyze/workflows/use-cases/	概要／説明	セキュリティワークフロー
作成テクニック	explore-analyze/workflows/authoring-techniques/	手順	ワークフローの管理と整理
コンセプト	explore-analyze/workflows/concepts/	説明	トリガー、ステップ、Liquid
リファレンス	explore-analyze/workflows/reference/	リファレンス	チートシート、ステップタイプの索引
チュートリアル	explore-analyze/workflows/get-started/	チュートリアル	最初のワークフローを作成する
ハブ／概要	explore-analyze/workflows/ またはセクションの索引	概要	ワークフロー、ユースケース

ページの種類が曖昧な場合は、/docs-content-type-checker を分類モードで実行します。インストールされていない場合は省略します。

ステップ2：執筆前に調査する

ステップの種類、パラメーター名、UI ラベルを推測してはいけません。まず事実を集めます。

公開済みドキュメント（優先）

https://www.elastic.co/docs/_mcp/ の elastic-docs MCP サーバーを使います（セットアップについては関連スキルとツールを参照）。MCP を利用できない場合は、同じ https://www.elastic.co/docs/... URL に対して WebFetch を使います。

1. search_docs — トピックや関連する構成要素について、既存のページを検索します
2. get_document_by_url — includeBody: true を指定して、関連ページ、テンプレート、ガイドラインを取得します
3. find_related_docs — 相互リンク先を見つけます

ドラフトを作成する前に、次の主要ドキュメントを必ず読みます。

リソース	URL パス
ワークフローハブ	/docs/explore-analyze/workflows
チートシート（注意点）	/docs/explore-analyze/workflows/reference/cheat-sheet
ステップタイプの索引	/docs/explore-analyze/workflows/reference/step-types
構成リファレンス	/docs/explore-analyze/workflows/authoring-techniques/anatomy
適切なステップを選ぶ	/docs/explore-analyze/workflows/authoring-techniques/choose-the-right-step

Kibana のソースコード

ステップタイプ、トリガー、または UI ワークフローをドキュメント化する場合：

1. Kibana リポジトリでステップタイプの識別子（例：elasticsearch.search、cases.addComment、kibana.SetAlertsStatus、slack.postMessage、foreach）を検索します
2. 例だけでなく、ステップ定義、スキーマ、またはコネクターアクションの登録を読みます
3. パラメーター名、必須フィールド、出力形式を確認します

Kibana での検索開始地点の候補です。まずステップタイプ ID で検索し、次にドキュメント化する内容に合ったパスを確認してください。

必要な情報	確認する場所
ステップのパラメーター、ワークフロー YAML スキーマ、非推奨項目	src/platform/packages/shared/kbn-workflows/spec/ — schema.ts、builtin_step_definitions.ts、builtin_trigger_definitions.ts、および名前空間ディレクトリ spec/elasticsearch/、spec/kibana/ から確認します
特定のステップタイプ（elasticsearch.search、cases.addComment、security.setAlertStatus、kibana.SetAlertsStatus、slack.postMessage、foreach など）	名前空間付きステップは kbn-workflows/spec/<namespace>/、foreach などの組み込みステップは builtin_step_definitions.ts を確認し、次にリポジトリ内の検索で登録プラグインを探します
トリガー（手動、スケジュール、アラート、イベント駆動）	kbn-workflows/spec/builtin_trigger_definitions.ts、登録プラグイン内の製品トリガー、workflows_extensions/dev_docs/TRIGGERS.md
UI ラベル、ステップメニュー、YAML エディター、オーサリング画面	src/platform/plugins/shared/workflows_management/public/；サーバー側のステップ検出は workflows_management/server/
実行ライフサイクル、エラー処理、ステップの出力形式	src/platform/plugins/shared/workflows_execution_engine/
カスタムステップまたは製品に登録されたステップ	src/platform/plugins/shared/workflows_extensions/；内部ガイドは workflows_extensions/dev_docs/STEPS.md
スタックコネクターのアクション	x-pack/platform/plugins/shared/stack_connectors/ と、x-pack/platform/plugins/ 配下のコネクター固有プラグイン

公式のワークフロー例は kbn-workflows/spec/examples/ にあります。スキーマに適合する YAML を確認する際は、elastic/workflows よりもこちらを優先してください。

注： x-pack/platform/plugins/shared/workflows/ はレガシーパスです。上記の src/platform/ レイアウトを使用してください。

既存の docs-content ファイル

ワークスペースに docs-content のチェックアウトがある場合：

• explore-analyze/workflows/ 配下の関連ページを読み、文体、構成、相互リンクを確認します
• 再利用可能なインクルードがないか、explore-analyze/workflows/_snippets/ を確認します
• ナビゲーション上の配置と、対象が children: を持つハブページかどうかを toc.yml で確認します

ワークフローの例

elastic/workflows ライブラリには YAML の例が含まれています。実用的な例を作成する際に使用できますが、ドキュメント化する前に、各ステップタイプとパラメーターをソースで確認してください。

ステップ 3：Workflows のオーサリングルールを適用する

これらの規約は必ず守ってください。注意点については、チートシートが正式な参照先です。

YAML の例

• ステップに焦点を当てた例では steps: ブロックを使用します。トリガー、入力、設定が重要な場合に限り、ワークフロー YAML 全体を含めます
• インデントは 2 つのスペースにし、例はコピー＆ペーストして使える状態にします
• ステップには内容が分かる名前を付けます（step1 ではなく search_for_alerts）
• ステップ間のデータフローを明示します（steps.<name>.output）

構文ルール

ルール	正しい例	誤った例
Liquid の配列／オブジェクト	"${{ event.alerts }}"	"{{ event.alerts }}"
Liquid の文字列	"{{ inputs.name }}"	—
data.filter／if 条件	KQL：item._source.severity : 'critical'	Liquid：== による比較
Cases ステップのパラメーター	case_id、comment（スネークケース）	caseId（キャメルケース）
名前空間付きステップ ID（cases.*、security.*、elasticsearch.*）	小文字のドット記法：security.setAlertStatus	パスカルケース（kibana.SetAlertsStatus）。ただし、レガシーステップ自体を説明する場合を除く
アラートステータスのステップ	kibana.SetAlertsStatus（パスカルケース）	kibana.set_alerts_status
AI ステップ識別子	トップレベルの connector-id、agent-id（そのままのケバブケース）	with の下にネストする、または Liquid テンプレート化する
JSON のシリアル化	| json、| json_parse	to_json（存在しません）
switch.cases	{ case:, steps: } オブジェクトの配列	case 値をキーにしたマップ／オブジェクト
workflow.execute のターゲット	with 内の workflow-id	トップレベルのフィールド

バージョンの違い

例で inputs を使う場合は、適用切り替えまたはタブを使って両方の配置を示してください。

• Stack 9.4 以前：トップレベルの inputs:
• Stack 9.5 以降および Serverless：type: manual トリガーの下にネストした inputs

正規のタブ用マークアップについては、anatomy.md を取得してください。

ライフサイクルと利用可否

ステップまたは機能のバージョンが限定されている場合は、プレビュー／GA ステータスと applies_to タグを明記してください。非推奨または名称変更されたステップ、トリガー、パラメーターについては、次のようにしてください。

• 新しいコンテンツでは、非推奨の形式ではなく、現在の置き換え先を説明します。
• 移行の文脈 — 非推奨の形式を示す場合は、インラインで非推奨と明記し、置き換え先のリファレンスにリンクします。
• 移行ガイド — Workflows のドキュメントセットで、バージョン固有の移行ページ（例：9.3 → 9.4）を検索してリンクします。例として kibana.createCase 形式のステップではなく cases.* を使いますが、それだけに限定しないでください。
• 優先する名前空間 — 新しい名前空間付きステップ（security.*、cases.*）とレガシーの kibana.* パスカルケースのステップが重複する場合、新しいワークフローでは名前空間付きステップを優先する方法として説明し、古いページには相互参照を追加します（kibana.md から cases.* を参照する方法に合わせます）。

ステップ 4：ページの下書きを作成する

ドキュメントに関する課題が提示されている場合は、明示的に延期された項目を除き、## Suggested documentation work (for the writer) のすべての項目に対応する内容を作成します。提案をそれぞれ、下書き内のセクション、例、またはフォローアップ編集に割り当ててください。

以下のセクションにあるページ種別ごとの構成に従ってください。H1 のパターン、導入段落、セクションの順序は、それぞれのセクションで定義されています。

Workflows ページでは、限られた数の MyST ディレクティブを使います。次の指示に従ってください。

• バージョンによる分岐 — Stack／Serverless のバージョンによって YAML が異なる場合（特に inputs の配置）は、applies-switch またはタブを使います。anatomy.md のマークアップをコピーし、タブ構文を独自に作らないでください。
• UI の操作手順 — 作成テクニックのページでのみ stepper を使います。
• スニペット — 一致するスニペットがある場合は、explore-analyze/workflows/_snippets/ から :::{include} を使います。

兄弟 Workflows ページを参照しても解決できないディレクティブに限り、/docs-syntax-help を参照してください。インストールされていない場合はスキップしてください。

Frontmatter

---
navigation_title: <Short nav label>   # omit on hub pages when title suffices
description: <One sentence describing this Workflows page's content>
products:
  - id: kibana
  - id: cloud-serverless    # include when feature is available on serverless
applies_to:
  stack: ga 9.4+            # adjust per feature availability
  serverless: ga
---

コンテンツ種別のガイドラインで必要な場合は、type: how-to または type: tutorial を追加してください。

ステップのリファレンスページ

ファイル：explore-analyze/workflows/steps/<topic>.md（または steps/ 配下のサブフォルダー）

課題で既存のステップページ（例：Cases のアクションステップ）を参考にするよう指定されている場合は、先に同じ階層にあるページを読み、新しい構成を考案するのではなく、そのレイアウトに合わせてください。

名前空間／アクションステップのファミリーページ（例：cases.md、security.md、kibana.md）では、次の構成を使用します。

1. H1 とアンカー — ステップファミリーの名前を付けます（例：「Security Triage and Investigation action steps」）。navigation_title は短くします（例：Security）。
2. 概要 — namespace.* ステップの機能、使用するタイミング、他のページにある重複するステップとの関係を説明します。
3. 共通の規約 — 各ステップの詳細より前に、名前空間全体に適用されるルールを記載します。
   • with 配下のパラメーター
   • 単一 ID フィールドと一括 ID フィールド
   • 該当する場合、追加／削除のセマンティクス（既存の値を保持し、完全に置き換えない）
   • 必須フィールドのルール（例：「追加または削除の少なくとも一方」）
   • 関連するステップグループ間のパラメーター名の違い — 実装どおりに記載し、表記を統一しないでください（例：alert_ids と ids、close_reason と reason）
4. ステップ一覧 — 各ステップへのジャンプリンクを、必要に応じてサブドメイン別（例：Alerts と Attacks）にまとめます。
5. ステップごとのセクション — 各ステップタイプについて、次を記載します。
   • 目的を説明する1文
   • パラメーター表：Parameter | Location | Type | Required | Description
   • YAML の例
6. ミラーページで使用している場合は、:::{include} ../_snippets/schema-location-legend.md ::: を含めます。
7. 関連項目 — 同じ階層にあるステップページ、トリガー、ステップタイプの一覧、チートシート

既存の名前空間ページに単一のステップタイプを追加する場合は、次を記載します。

• 必須および任意の with パラメーター（上記の形式の表）
• トップレベルフィールド（connector-id、if、foreach、on-failure など）
• 出力の形式（steps.<name>.output）
• 簡潔な例を1つと、役立つ場合は現実的な複数ステップの例を1つ
• そのステップ固有の注意点

新しい名前空間ページまたはステップの作成後、次の追加編集を列挙します。

• steps/action-steps.md — 新しいステップファミリーを追加する場合、カテゴリの説明とリンクを追加します。
• reference/step-types.md — 新しいステップタイプごとに行を追加します。
• reference/cheat-sheet.md — 行を追加するか、タスク別のグループ分け（例：「アラートを管理する」「攻撃を管理する」）を更新します。
• 重複する同階層のページ — 推奨する名前空間を相互参照します（例：kibana.md → security.*）。

ユースケースページ

ファイル：explore-analyze/workflows/use-cases/<domain>.md

構成：

1. H1 とアンカー — ドメインに焦点を当てたタイトル（例：「Security workflows」）
2. 概要 — このドメインでチームがワークフローを使って達成できることを説明します。
3. パターンのセクション — ステップタイプ別ではなく、目的別にまとめます。
   • 自動化できる内容（箇条書きで成果を列挙）
   • 典型的なトリガーとステップパターン（簡潔に記載し、ステップ／トリガーのリファレンスへのリンクを付ける）
   • ワークフローの例やテンプレートがある場合は、そのリンクを示します。
4. 関連項目 — 関連するステップのリファレンス、作成テクニック、チュートリアルへのリンク

ユースケースページはステップのリファレンスより短くします。パラメーター表を重複して記載するのではなく、リンクを使用してください。

作成手法ページ（ハウツー）

ファイル：explore-analyze/workflows/authoring-techniques/<action-verb-topic>.md

ハウツーのコンテンツタイプに関するガイドラインに従います。

1. 動詞で始まるH1 — 例：「ワークフローの実行を監視する」
2. 概要 — 読者が達成できること
3. 開始前に — 権限、前提条件、UIへのアクセス方法
4. 番号付き手順 — 命令形の動詞を使い、各手順では1つの操作を説明します。UIの操作手順にはstepperを使用します
5. 成功の確認ポイント — 重要な各手順が機能したことを確認する方法
6. 次のステップと関連項目

ハウツーは10手順以内に収めます。対象範囲が広い場合は、チュートリアルにつなげます。

概念ページとリファレンスページ

概念ページでは、トリガー、ステップ、データフロー、Liquid、エラー処理について説明します。メンタルモデルと、詳細を説明するリファレンスへのリンクに重点を置きます。

リファレンスページ（構造、チートシート、コンテキスト変数）では、表、フィールドごとの説明、バージョンタブを使用します。パラメーター一覧は、文章より表を優先します。

チュートリアルページ

ファイル：explore-analyze/workflows/get-started/<topic>.md

チュートリアルのコンテンツタイプに関するガイドラインに従います。説明を加えながら複数のタスクをつなげます。サンプルデータのセットアップ、確認ポイント、「作成したもの」のまとめを含めます。

ステップ 5：相互リンクとナビゲーション

ドラフトの作成後：

1. ハブページ、ステップタイプのインデックス、チートシート、または適切なステップの選び方ページから、新しいページへのリンクを追加します
2. 新しいページの末尾に関連項目セクションを追加します（リンクを3～5件）
3. 新しいステップファミリーを追加する場合は、steps/action-steps.mdを更新します。既存のカテゴリ説明（短い説明、「Use … to:」の箇条書き、Refer to …リンク）に合わせます
4. 課題で納品物として指定されている場合は、reference/step-types.mdとreference/cheat-sheet.mdを更新します。主要ページのドラフト作成だけで終わらせないでください
5. 重複する兄弟ページに、優先する名前空間への相互参照を追加します（例：新しいアラートトリアージのワークフローを、kibana.SetAlertsStatusからsecurity.setAlertStatusへ誘導します）
6. 新しいファイルを追加する場合はtoc.ymlを更新します（配置をユーザーに確認します）
7. ハブページの重複コンテンツを削除します。ハブページでは要約とリンクを提供し、リファレンスの詳細を繰り返しません

ステップ 6：検証

ドラフトを提示する前に：

1. インストールされている場合は、ドラフトに対して/docs-content-type-checkerを実行します。利用できない場合は、ステップ4のページタイプ別テンプレートに照らして構成を確認します
2. 外部リンクを検証します。ファイルパスがある場合は、elastic-docs MCPのget_document_by_url（またはWebFetch）を使って、ドラフト内の各相互リンクが解決できることを確認します
3. YAMLの例を、チートシートの注意点リストに照らして抜き取り確認します
4. ステップタイプとパラメーター名をKibanaのソースコードと照合します
5. ドラフトを推奨されるドキュメント作業の表と照合します。延期されていない項目はすべて対応するか、説明を加えてください

ソースコードで検証できなかった項目を報告します。利用できなかった関連スキルやMCPツールも記載します。

出力形式

次の内容を提示します。

1. 受付概要 — 課題へのリンク、対象範囲、推奨されるドキュメント作業（項目ごとのステータス付き）、解決済みおよび未解決の質問（課題を使用していない場合は省略）
2. ページ分類 — 種類、対象ファイルパス、分類の根拠
3. 調査概要 — 読んだソースページ、参照したKibanaファイル
4. ドラフトの内容 — frontmatterを含む、docs-contentに書き込める完全なMarkdown
5. 追加の編集 — 更新が必要なその他のファイル（インデックス、toc.yml、ハブページのリンク）。推奨されるドキュメント作業のうち、延期した項目も含めます
6. 未解決の質問 — ドラフト作成後もSMEによる確認が必要な事項

ユーザーがファイルパスを指定した場合は、そのパスにドラフトを書き込みます。指定がない場合は、パスを提案し、内容を確認用に提示します。