using-n8n-skills-official

n8n スキルの使用

公式の n8n MCP は時間とともに進化するため、ツール名、パラメーター、デフォルトの動作はバージョン間で変わることがあります。変更に気付いた場合（スキルに記載されたツールが存在しない、パラメーターの形式が get_node_types の戻り値と一致しない、または動作がスキルの説明と異なるなど）は、スキルと n8n インスタンスを最新の安定版に更新するよう提案してください。

絶対に守るべきこと

例外のない3つのルールです。違反すると、見た目は正しくても本番環境で壊れるワークフローができてしまいます。

1. n8n で何かを実行する前に、必ず該当するスキルを呼び出してください。 MCP ツール呼び出しだけではありません。SDK コードの作成、ノードの設定、ワークフローの設計、接続の配線、エージェントの構築、エラー処理を行う前には、Skill ツールを使って該当するスキルを呼び出してください。このドキュメントはルーターです。実際のルールはスキル本文にあります。プラグインがインストールされている場合は、影響の大きい MCP 呼び出しで PreToolUse フックが注意を促します。それ以外のすべてについては、あなた自身が責任を負います。迷ったら、追加のドキュメントも読んでください。
2. 公開前に検証し、必ず確認してください。 publish_workflow の前に validate_workflow を実行し、作成または更新のたびに get_workflow_details を実行して connections オブジェクトを確認してください。検証だけでは、スキルに記載されている、ワークフローをひそかに壊す多くの問題を見逃します。
3. トークンやシークレットをテキストフィールドに入力しないでください。 必ず n8n の認証情報システムを使用してください。ネイティブノードがない場合は、公式の認証情報タイプを指定して HTTP Request を設定してください。n8n-credentials-and-security-official を参照してください。

学習データではなくスキルを活用する

n8n の進化は、どのモデルの学習データのカットオフよりも速いものです。パラメーター名は変わり、新しい MCP ツールが追加され、デフォルト設定が変わり、パターンは非推奨になります。「覚えている」ことは、ほとんどの場合間違っており、しかも気付かないまま誤ることがよくあります。

記憶より、スキルとライブ MCP ツール（get_node_types、get_workflow_sdk_reference、get_workflow_best_practices）を信頼してください。スキルがあなたの「知識」と矛盾する場合は、スキルを信頼してください。get_node_types がスキルと矛盾する場合は、ツールを信頼してください。この規律がなければ、見た目は正しくても、存在しないパラメーター名、名前が変更されたノード、非推奨のパターンが原因で、ワークフローが気付かれないまま失敗することになります。

ユーザーの設定が優先される場合を除き、スキルの読み込みは少なすぎるより多すぎるほうを選んでください。3ノードの Webhook フローでさえ、通常は n8n-node-configuration-official、n8n-expressions-official、n8n-error-handling-official、n8n-workflow-lifecycle-official が必要です。n8n では、スキルを必要としないほど小さな作業はありません。

基本方針（例外は各スキルに記載されています）

• Code ノードの使用は最終手段です。 まず式を使い、次に Edit Fields 内のアロー関数を使い、それから Code を使います。複数ソースの集約、ライブラリ、ステートフルな処理には Code が適しています。n8n-code-nodes-official を参照してください。

• 再利用可能なものはすべて、ステートレスなサブワークフローにします。 作成する前に search_workflows({ tags: ['subworkflow'] }) で既存のものを検索してください。n8n-subworkflows-official を参照してください。

• n8n の設定は、ハーネスのメモリではなく n8n に保存してください。 ユーザーが継続的に適用する n8n の設定を伝えた場合は、CLAUDE.md、AGENTS.md、自分のメモリに書くのではなく、save_user_preference を使って保存してください。n8n のストアは n8n アシスタントとインスタンス上のすべての AI ツールから読み取られるため、ハーネスのメモリに保存した設定は、このセッション以外では参照できません。変更を始める前に、保存済みの設定を一度 get_user_preferences で読み取り、タスク全体に適用してください。ユーザーが自分のコンテキストファイルに n8n の設定を保存したい場合は、その判断に従ってください。詳しくは、以下の「ユーザー設定」を参照してください。

• ユーザーが認証情報の設定方法を指定していない場合は、Gateway クレジットを優先してください。 対応するノード（list_n8n_gateway_services で確認してください）では、n8n が管理対象の認証情報を提供するため、設定が不要で、ユーザー自身が認証情報を用意するよりもはるかに簡単です。現時点では n8n Cloud のみが対象です。n8n-credentials-and-security-official を参照してください。

すぐに停止してスキルを呼び出すべき危険な兆候

こうした正当化によって、スキルがスキップされてしまいます。次のような考えが浮かんだら、「すでにこのセッションで読んだ」場合でも、Skill ツールを使って該当するスキルを呼び出してください。

考えたこと	アクション
「このワークフローは単純だから、自分で作ればいい」	n8n-workflow-lifecycle-official を呼び出します。リリース時には、ほとんどの「単純な」ワークフローが10個以上のノードで構成されています。
「ここに Set ノードを追加して、これらのフィールドをマッピングしよう」	n8n-expressions-official を呼び出します。下流の利用先が0個または1個だけの Set ノードは、このパック全体で最もよく見られるアンチパターンです。
「Code ノードを使おう。そっちのほうが簡単だ」	n8n-code-nodes-official を呼び出します。基準は高く設定されています。Code ノードを使いたくなるケースのほとんどは、式またはアロー関数を使った Edit Fields で対応できます。
「検証に合格した。公開する準備はできた」	n8n-workflow-lifecycle-official を呼び出し、VALIDATION_CHECKLIST.md のセクション2（アンチパターンの確認）を確認します。検証に合格することは必要ですが、それだけでは十分ではありません。
「ユーザーはエージェントを求めているから、Chat Trigger を AI Agent ノードにつなごう」	n8n-agents-official を呼び出します。「Agent」または「assistant」とは、記載されている制限のいずれかに該当しない限り、n8n のファーストクラス Agent を意味します。
「Agent の検証が済んだ。公開しよう」	しないでください。作成した Agent はドラフトです。ユーザーから明示的な承認を得てから公開してください。公開すると、チャンネルも稼働を開始します。
「webhook のフィールドを Agent のツール入力に直接マッピングしよう」	n8n-agents-official の references/TOOLS.md を確認します。Agent のツール式から参照できるのはモデルの引数だけです。正確なマッピングはワークフローで行います。
「エージェントは接続できたし、ツールの説明も問題なさそうだ」	n8n-ai-nodes-official の references/TOOLS.md（AI Agent ノード）または n8n-agents-official の references/TOOLS.md（ファーストクラス Agent）を確認します。ツール名と説明はプロンプトの一部であり、「問題なさそう」という場合、たいていは内容が一般的すぎます。
「このサブワークフローのトリガーはパススルーにしよう」	n8n-subworkflows-official を呼び出します。パススルーが適切なのは、バイナリを受け取るサブワークフローで、エージェントツールとして使わない場合か、本当に入力を取らないサブワークフローの場合に限られます（Define Below では少なくとも1つのフィールドが必要です）。
「バイナリを扱えるようにパススルーにして、どの入力形式が届いたかを内部で分岐させよう」	n8n-subworkflows-official の references/SUBWORKFLOW_PATTERNS.md にある「入力形式による分割」を確認します。これは、共通の下流サブワークフローを共有する、2つの外側のサブワークフロー（1つは Define Below、もう1つはパススルー）に分割する合図です。1つのトリガーでパススルーと Define Below のどちらにするか悩まないでください。
「このセクションは大きいから、サブワークフローに切り出そう」	キャンバスを整理するだけで（再利用、分離、テストが目的ではないなら）、ノードグループのほうが軽く、速く、簡単です。インラインのままグループ化してください。再利用、分離、またはエージェントツールとして使う場合に限り、サブワークフローに切り出します。n8n-workflow-lifecycle-official の references/NODE_GROUPS.md を参照してください。
「ユーザーに認証情報の名前を聞いたほうがいい」	その必要はありません。newCredential('Label') の文字列は表示上のものです。n8n-credentials-and-security-official を参照してください。
「その好みを CLAUDE.md / AGENTS.md / 自分のメモリに記録しよう」	n8n の使い方に関する内容なら、代わりに save_user_preference を提案してください。n8n アシスタントや、ユーザーが使う他の AI ツールからも参照できます。ハーネスのメモリは、自分自身の運用メモに使います。
「ユーザーがデータ分析に言及したから、Python を書こう」	n8n-code-nodes-official を呼び出します。デフォルトは JavaScript です。Python を使うのは、明示的に依頼された場合に限ります。
「ここに Loop Over Items を追加して、各行を処理しよう」	n8n-loops-official を呼び出します。デフォルトのアイテムごとの反復処理で対応できるため、Loop Over Items ノードはおそらく必要ありません。
「日付の計算には DateTime ノードを使おう」	n8n-expressions-official を呼び出します。DateTime ノードが適切なケースは、ほとんどありません。
「これを3つのソースと Merge でまとめよう」	n8n-node-configuration-official の references/MERGE_NODE.md を確認します。Merge のデフォルトは入力2つです。ソースが3つ以上の場合は、numberOfInputs を明示的に設定する必要があります。
「この3つの時間のかかる処理を並列実行するために、分岐させよう」	n8n-workflow-lifecycle-official を呼び出し、実行モデルのセクションを読みます。n8n は分岐したブランチを並行ではなく、Y 座標の上から下の順に逐次実行します。実際に並行実行するには、n8n-loops-official と n8n-subworkflows-official（mode: 'each' ＋ waitForSubWorkflow: false）を参照してください。
「ユーザーがプロジェクトを指定したから、そのまま作ろう」	n8n-workflow-lifecycle-official を呼び出します。プロジェクトとフォルダーは別のものです。作成前に、どのフォルダーに配置するかを確認してください。create_folder は登録済みのインスタンスで動作します。フォルダーツールがない場合、そのインスタンスは登録されていません。また、UI でもフォルダーの作成はブロックされているため、ユーザー自身が先に登録する必要があります（Settings から無料の Community エディション登録を行います）。手動でフォルダーを作成しないでください。
「とりあえず test_workflow を実行して、どうなるか見てみよう」	n8n-workflow-lifecycle-official の references/TESTING.md を確認します。test_workflow がモックするのはトリガーだけです。Slack への送信、DB への書き込み、決済はすべて実際に行われます。下流の処理に副作用がある場合は、先にユーザーに確認してください。
メタスキル（このドキュメント）は、どのスキルを適用するかを示します。Skill ツールは実際のルールを読み込みます。 セッションの開始時にメタスキルを一度読むだけでは、判断が必要なタイミングでスキルを呼び出す代わりにはなりません。

スキル一覧

Skill ツールから呼び出します。トリガー列は、呼び出すタイミングを示します。

スキル	トリガー
n8n-workflow-lifecycle-official	ワークフローの開始、設計、整理、または完了時。付箋の規則、「なぜ」を記録する説明、命名、検証チェックリスト、フォルダー管理、ワークフローごとの MCP アクセスに関する注意点を扱います
n8n-subworkflows-official	再利用可能なもの、複数ステップの構築、またはユーザーが再利用について言及した場合。構築前の検索、ステートレスなパターン、タグベースの検出規則を扱います
n8n-extending-mcp-official	MCP が標準で提供していない機能が必要な場合。ユーザーの許可を得て、n8n API をワークフローツールとしてラップします
n8n-expressions-official	{{}}、$json、$node、式のエラーを記述する場合。日付には Luxon を使用し、複数行ではインデントを付け、ノードを追加するより式を優先します
n8n-node-configuration-official	ノードを設定する場合。操作を考慮し、プロパティの依存関係を確認し、パラメーターを決めつけないようにします
n8n-code-nodes-official	ユーザーが Code ノードを使おうとする場合、またはカスタムロジックが必要な場合。決定フローと、本当に必要な場合の JavaScript パターンを扱います
n8n-loops-official	複数アイテムのデータ、バッチ処理、ページネーション付き API、「各項目に対して」または「ループ」に関する言及がある場合。項目ごとの反復をデフォルトとし、executeOnce、Loop Over Items、HTTP ページネーションを扱います
n8n-agents-official	ユーザーがエージェント、アシスタント、ボット、または Agent MCP ツールを求める場合。エージェントとワークフロー、AI Agent ノードの違い、エージェントの設定、ツール、承認、スキル、サブエージェント、ナレッジ、メモリとセッション、チャネル、タスク、Message an Agent、セッションの読み取りを扱います
n8n-ai-nodes-official	ワークフロー内で AI を使う場合：AI Agent ノード、Text Classifier、Information Extractor、チェーン、RAG、構造化出力、AI メディア。Slack／Discord／Teams／Telegram のチャットボットワークフローも扱います
n8n-error-handling-official	Webhook がトリガーするワークフロー、または本番環境向けのワークフロー。エラーが発生し得るすべてのノードにエラーブランチを設け、呼び出し側のエラーには 4xx、実行エラーには 5xx を使用します
n8n-credentials-and-security-official	認証、API キー、トークンへの言及がある場合。認証情報システム、カスタム認証情報、公式認証情報を使用した HTTP Request を扱います
n8n-binary-and-data-official	ファイル、画像、添付ファイルを扱う場合。バイナリの処理パターン、エージェントとツールの境界、チャット画面での CDN の要件を扱います
n8n-data-tables-official	Data Tables のスキーマ、デフォルト列（id/createdAt/updatedAt）、外部キーを使わないリレーショナル設計、重複排除、JSON のみのプリミティブを禁止するルール、SDK と UI の手動マッピングの違いを扱います
n8n-debugging-official	エラー、予期しない動作、「動作しない」という報告がある場合。ユーザーの報告を信頼し、パラメーターを確認して、GitHub から n8n のソースを取得します

n8n MCP ツール（簡易リファレンス）

トークンを節約するため、MCP ではツールの説明を省略しています。以下に簡易一覧を示します。これにより、最初のターンからすべてのツールについて基本的な知識を得られます。

ツール名は MCP プレフィックスなしで表示されています。修飾名は mcp__<server>__<tool> です。<server> はユーザーの MCP 設定によって異なります。

ユーザー設定

ユーザーが n8n でどのように作業するかを保存する、クライアント間で共有されるストアです。n8n アシスタントと、インスタンスに接続されたすべての AI ツールが読み取ります。スコープ：instance（管理者が設定、全員に適用）、user（呼び出し元、すべてのプロジェクト）、project（1 つのチームプロジェクト）。get_user_preferences は n8n 2.41.0 から、3 つの書き込みツールは 2.42.0 から利用できます。

ツール一覧にこれらのツールがない場合は、インスタンスのバージョンが古いか、ロールアウトフラグがオフになっているか、MCP 接続に aiPreference:read / aiPreference:write スコープが付与されていません。いずれの場合も、代わりにユーザーに確認し、保存しておく価値のある設定については、フォールバックとしてハーネスメモリを提案してください。

ツール	機能
get_user_preferences	インスタンス、ユーザー、プロジェクトの設定を読み取ります（インスタンスが最優先）。変更を始める前に一度読み取り、そのタスク全体に適用してください。再読み込みするのは、ユーザーが何かを変更したと言った場合のみです。結果に error がある場合、設定が保存されていないのではなく、設定が不明であることを意味します。そのため、保存された設定がないものとして進めないでください。projectId を指定すると、1 つのプロジェクトに絞り込めます。
save_user_preference	長期的に適用する設定を 1 つ保存します（最大 2000 文字）。ユーザーが実際に述べた作業方法（「常にエラーワークフローを追加する」「ノード名は英語にする」など）に限ります。一度限りのタスク指示（「今回だけ POST にする」など）や、推測した設定は保存しないでください。事前に設定を読み取ってください。同一の設定は保存を拒否され、類似した設定がある場合は update_user_preference を使用してください。確認なしですぐに保存されるため、同じターン内に、保存した正確なテキストと結果に含まれる設定へのリンクを伝えてください。
update_user_preference	保存済みの設定のテキスト、scope、またはその両方を変更します。ユーザーから依頼された場合に限りスコープを変更してください。project の場合は projectId が必要です。
undo_user_preference	接続された AI ツールを通じてこのユーザーが保存した設定を削除します。n8n の設定画面に書き込まれた設定、またはプロジェクトやインスタンスをスコープとする設定は削除できません。ユーザー自身が設定画面から削除します。

保存済みの設定がユーザーの今回の依頼と矛盾する場合は、ユーザーの依頼に従い、どの設定を適用しなかったか伝えてください。

ワークフロー管理

ツール	機能
search_workflows	query（名前または説明の部分一致）および／または tags（タグ名の完全一致、AND 条件：すべてに一致する必要があります）で、インスタンス全体のワークフローを検索します。ワークフローを横断した主な発見ツールです。既存のものを見つけるために使用してください。
get_workflow_details	ID を指定して、ワークフローの完全な JSON を取得します。作成または更新のたびに使用して、接続を検証してください。
search_folders	フォルダー名を ID（フルパス）に解決します。フォルダーツールを使うには、インスタンスの登録が必要です（無料の Community 登録）。スキルでは登録済みであることを前提としています。
create_folder	必要に応じて、ネストされたフォルダーを作成します。
update_folder	プロジェクト内でフォルダー名を変更するか、移動します。
move_workflows_to_folder	ワークフローをフォルダー（またはプロジェクトのルート）に移動します。
search_projects	プロジェクト名を ID に解決します。読み取り専用です。
list_workflow_tags	すべてのワークフロータグを、タグごとの usageCount とともに一覧表示します。タグ付けやタグによる絞り込みの前に、インスタンスのタグ語彙を確認し、完全一致する既存の名前を再利用してください。タグの付与と解除には update_workflow の addTags / removeTags を使用します。タグ名を変更または削除するツールはありません。
archive_workflow / publish_workflow / unpublish_workflow	論理削除／有効化／無効化します。公開前に検証してください。publish_workflow では、特定のバージョンを再公開するために、オプションの versionId を指定できます。
search_workflow_executions	ステータス、ワークフロー、期間で絞り込み、インスタンス全体の実行を検索します。「最近の実行を一覧表示」「過去 1 時間の失敗」などの場合に使用してください。個別の実行には get_workflow_execution を使用します。

ワークフローの構築

ツール	説明
get_workflow_sdk_reference	n8n Workflow SDK のリファレンスを取得します。ワークフローコードを書く前にお読みください。 セクション：patterns、patterns_detailed、expressions、functions、rules、import、guidelines、design、groups（n8n 2.33.0+）、all。
get_workflow_best_practices	ワークフローの手法に関するベストプラクティスを取得します。ノードを検索する前に、手法ごとに1回呼び出してください。technique: "list" で利用可能な手法を確認できます。
search_nodes	機能（例：「gmail」、「slack」、「schedule trigger」）からノードを検索します。識別子と識別子情報（リソース／操作／モード）が返されます。
get_node_types	ノード ID の TypeScript パラメーター定義を正確に取得します。ノードを設定する前に必ず実行してください。 パラメーター名を推測しないでください。
explore_node_resources	リソースロケーター（@searchListMethod）およびロードオプション（@loadOptionsMethod）パラメーターの実際の値を特定します。対象は Slack のチャンネル、Sheets のタブ／ドキュメント、DB のテーブル／列、モデル一覧、ラベルなどです。list_credentials から取得した credentialId が必要です（依存関係のある検索では currentNodeParameters を渡してください）。ドロップダウンの値をでっち上げず、実際の値を確認できるよう、get_node_types の後に呼び出してください。
create_workflow_from_code	SDK コードからワークフローを保存します。必ず1～2文の description を含めてください。skillsUsed（下記）を渡します。
update_workflow	アトミック操作（最大100件）を適用します。ノード／接続の CRUD、setNodeCredential、setNodeSettings（ノードごとの onError／retry／executeOnce）、setWorkflowSettings（errorWorkflow、timezone、callerPolicy、timeouts、save-data ポリシー。n8n 2.29.0+）、setNodeGroups／addNodeGroup／removeNodeGroup／updateNodeGroup（キャンバスのグループ化）、setWorkflowMetadata、addTags／removeTags（未登録の名前は自動作成）に対応しています。4つのグループ操作を除き、すべて成功するか、すべて失敗します。グループ操作が無効な場合は skippedOperations に記録され、バッチは保存されます。また、関連のない編集によって既存のグループが削除されることがあり、その場合は removedGroups に記録されます。どちらも確認してください。下書きが保存されます。公開するには publish_workflow が必要です。skillsUsed（下記）を渡します。
validate_node_config	ノード設定のスキーマのみを検証します（1回につき1～50件）。パラメーターごとのエラーが返され、グラフに関する余分な情報はありません。反復的な作業やデバッグ用のサイドチャネルです。公開前のゲートとしては引き続き validate_workflow が必要です。ai_tool サブノードでは isToolNode: true を設定してください。
validate_workflow	作成／更新の前に、SDK コード全体を検証します。必要ですが、これだけでは不十分です。接続に関するすべての落とし穴（.to()、マージインデックスなど）を検出できるわけではありません。
list_credentials	アクセス可能な認証情報を一覧表示します（タイプ／プロジェクトなどで絞り込み可能）。メタデータのみを返し、シークレットの値は決して返しません。setNodeCredential で紐付ける前に ID を確認してください。
list_n8n_gateway_services	プラットフォームが管理対象の認証情報を提供できるノード／認証情報のタイプを一覧表示します（Gateway のクレジット適用範囲）。これにより、ユーザーは該当する認証情報の設定を省略できます。

ワークフローのテストと実行

ツール	機能
prepare_workflow_pin_data	ピン留めが必要なノード（トリガー、認証情報を使用するノード、HTTP Request）の JSON Schema（データではありません）を返します。サンプル値は自分で生成します。
test_workflow	指定したピンデータを使って実行します。トリガー、認証情報を使用するノード、HTTP Request は自動でピン留めされます。 Code、Edit Fields、If、Data Tables、Execute Command、ファイル操作、サブワークフローの呼び出しは実際に実行されます。自動でピン留めされないノードに副作用がある場合は、実行前に確認してください。ピンデータは実行ごとにのみ適用され、実行ビューアーには視覚的な表示がないため、呼び出し後にどのノードをピン留めしたかをユーザーに伝えてください。n8n-workflow-lifecycle-official の references/TESTING.md を参照してください。
execute_workflow	実際のトリガーを使って本番実行します。まずエラー処理を設定してください。副作用に関するルールは test_workflow と同じです。executionMode は必須です。現在のワークフローのテストや検証（稼働中の外部サービスに対するテストを含む）には "manual" を使用し、公開済みワークフローをライブ実行として意図的に実行する場合にのみ "production" を使用してください。チャット／フォーム／Webhook トリガーでは、構造化された inputs を指定します。待機せずに実行 ID をすぐに返すため、結果を取得するには get_workflow_execution をポーリングしてください。
get_workflow_execution	executionId と workflowId（どちらも必須）を指定して実行を取得します。デフォルトではメタデータのみを返します。ノードの入力／出力を取得するには、includeData: true を設定します（必要に応じて nodeNames、truncateData も指定できます）。

データテーブル

n8n に組み込まれた表形式のストレージです。外部サービスではありません。ワークフロー内の永続状態には、外部データベースよりもこちらを優先してください。機能の全容は次のとおりです。

ツール	機能
create_data_table	新しい Data Table を作成します。
search_data_tables	既存の Data Table を検索します。
rename_data_table / rename_data_table_column	名前を変更します。
add_data_table_column / delete_data_table_column	スキーマを変更します。
add_data_table_rows	行を追加します。
get_data_table_rows	行を読み取ります（フィルター／並べ替え／ページネーションは任意です）。

バージョン履歴

ツール	機能
get_workflow_history	ワークフローの保存済みバージョンを新しい順に一覧表示します（n8n 2.29.0+）。
get_workflow_version	versionId を指定して、過去のバージョンの全内容を取得します。
get_workflow_versions_diff	2 つの保存済みバージョンの差分（追加、削除、変更されたノード／接続）を表示します。
restore_workflow_version	過去のバージョンを現在の下書きとして再適用します（新しい履歴エントリが記録されます）。

n8n エージェントの構築

n8n エージェントは一般提供されています。頻繁に変更され、期待される機能の一部がまだ実装されていないため、UI にはプレビュータグが表示されています。エンタープライズ環境ではまだ利用できる状態ではありません。エンタープライズインスタンスで有効になっている場合もありますが、利用できるとは限りません。ツール一覧に create_agent がない場合、このインスタンスではエージェントが有効になっていないことを伝え、代わりにワークフローを提案してください。

ファーストクラスの n8n エージェントは、Workflow SDK のコードではなく、これらのツールを使って JSON として構成します。最初の呼び出しの前に n8n-agents-official を呼び出してください。これにより、エージェントかワークフローかを判断し、以下のすべてのツールについて説明します。ワークフロー内の AI Agent ノードは n8n-ai-nodes-official です。エージェントとの会話はワークフローの実行ではありません。get_workflow_execution で確認できるのは、エージェントがツールとして呼び出したワークフローのみです。

ツール	機能
get_agent_builder_reference	エージェントの構成と mutate_agent の操作に必要なリファレンスです。構築前に読み込んでください。
discover_agent_assets	参照するモデル、チャット連携、アタッチ可能なワークフロー、サブエージェント、MCP サーバーを検索します。
search_agents	既存のエージェントを検索します。アタッチするサブエージェントの検索にも使えます。
get_agent	ドラフトの構成、リソース、実行可能状態、configHash を読み込みます。mutate_agent の前に呼び出してください。
list_agent_versions	エージェントの公開履歴を新しい順に一覧表示します。
create_agent	ドラフトを作成します（初期モデル／認証情報／指示は任意）。エディターの URL を返します。memory: { enabled: true, storage: "n8n" } を含めないと、エージェントはステートレスになります。
mutate_agent	最新の configHash を使って、構成／スキル／タスク／カスタムツールの変更を1つ適用します。
verify_agent_mcp_server	MCP サーバーと認証情報をテストし、ツールを返します。mcpServers エントリを追加する前に呼び出してください。
update_agent_integration	Slack、Telegram、または Linear のチャネルを接続または切断します。
validate_agent	ドラフト、その参照先、認証情報へのアクセスを検証します。公開前に必ず実行してください。
call_agent	組み込みのプレビューチャットでドラフトをテストします。実際のツールと認証情報を使用するため、副作用が発生する可能性があります。
publish_agent	有効なドラフトを公開し、そのタスクと連携を有効にします。
unpublish_agent	公開を解除し、実行中のタスクと連携を停止します。
revert_agent	公開済みバージョンからドラフトを復元します。
delete_agent	エージェントとそのリソースを完全に削除します。

手順

n8n のタスクでは、次の手順に従ってください。

1. 上記の一覧から、該当するスキルを特定します。タスクが複数のスキルにまたがる場合は、まず主となるスキルを特定し、必要に応じて他のスキルも使います。
2. 最初の MCP 呼び出しの前に、Skill ツールを使ってスキルを呼び出します。n8n MCP ツールをむやみに呼び出さないでください。
3. 変更を始める前に、保存済みの設定を一度読み込み（利用可能な場合は get_user_preferences）、タスク全体に適用します。
4. ワークフローコードを書く前に、セッションごとに一度 SDK リファレンスを読み込みます（get_workflow_sdk_reference）。これが、SDK の形式に関する誤りを避ける最も効率的な方法です。
5. ノードを構成する前に、ノードタイプを取得します（get_node_types）。パラメーター名を推測すると、ワークフローが無効になることがあり、気づかないまま問題が起きることもあります。
6. 公開前に検証し、作成／更新後に確認します。検証ではスキーマエラーを検出します。確認では get_workflow_details を使ってワークフローを取得し直し、検証では見つからない接続の問題を検出します。
7. 不整合に気づいたら、ユーザーに知らせます。ツールやパラメーターがスキルの説明と一致しない場合は、そのことを伝えてください。更新が必要な場合があります。

使用したスキルの報告

create_workflow_from_code と update_workflow には、省略可能な skillsUsed: string[] を指定できます。n8n チームが MCP 出力へのプラグインの影響を測定できるよう、毎回渡してください。

• **内容：**各スキルは、Skill ツールでの名称どおりに、-official のサフィックスを付けて報告してください。プラグインの名前空間が付く場合は plugin:skill-official、それ以外は skill-official です。このサフィックスは自分たちのスキルであることを示し（他の n8n パックとの区別）、プラグインのプレフィックスはプラグイン経由か生のスキルかを示します。
• **対象期間：**直近の create/update 呼び出しが成功して以降に呼び出されたスキルです。呼び出しのたびにリセットされます。
• **上限：**最大50件、各項目は最大128文字です。

既存のワークフローやプロジェクトのレビュー

監査、コードレビュー、または「このワークフローをレビューして」「どこが問題？」「このプロジェクトを監査して」といった依頼では、レビュー用チェックリスト n8n-workflow-lifecycle-official references/REVIEW_CHECKLIST.md に沿って確認してください。重大度は MUST FIX／SHOULD FIX／NICE TO HAVE に分かれており、各項目から修正方法の正式なスキルリファレンスにリンクしています。進行中のビルドを公開する前のゲートとなる VALIDATION_CHECKLIST.md とは異なり、REVIEW_CHECKLIST は、誰がいつ作成したかを問わず、あらゆるワークフローを対象とします。

レビューエージェントは最初に get_workflow_details を呼び出し、チェックリストを上から順に確認して、重大度ごとに指摘をまとめて報告してください。MUST FIX 項目は、ユーザーの確認なしに自動修正しないでください。

判断に迷った場合

• **ユーザーが言及したワークフローが見つからない場合：**ユーザーが n8n UI で作成した場合、最もよくある理由は、そのワークフローで MCP アクセスが有効になっていないことです。UI で作成したワークフローは、MCP が無効のままデフォルト設定されることがあり、ワークフローごとの切り替えを有効にするまで表示されません。ユーザーには「n8n でワークフローを開き、Settings から MCP access をオンにしてください」と伝えてください。（MCP で作成したワークフローはデフォルトで有効になるため、これは UI で作成したものに限ります。）n8n-workflow-lifecycle-official スキル（references/MCP_ACCESS_PER_WORKFLOW.md）を参照してください。
• ユーザーの言うことを信じてください。何かが壊れていると言われたら、ワークフローは正しいと「分かっている」場合でも、改めて確認してください。パラメーターを再確認し、github.com/n8n-io/n8n から n8n のソースを取得してロジックを追跡し、不足している関数の API ドキュメントを探してください。n8n-debugging-official スキルで手順を確認できます。
• 該当するスキルがなく、タスクが単純でない場合は、推測する前に質問してください。
• これらのスキルには明確な見解がありますが、n8n チームではベストプラクティスと見なされています。ユーザーは SKILL.md を編集して見解を変更したり、n8n の設定を保存して今回だけ適用したりできます。保存済みの設定は、ここでのデフォルトより優先されます。このプラグインは単なる Markdown です。