using-n8n-skills

n8n スキルの使用

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

絶対に守るべきこと

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

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

トレーニングデータではなくスキルを頼りにする

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

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

ユーザーの好みによる指定がない限り、スキルは少なすぎるより多めに読み込むようにしてください。3 ノードの Webhook フローでさえ、通常は n8n-node-configuration、n8n-expressions、n8n-error-handling、n8n-workflow-lifecycle が必要です。スキルを必要としないほど小さなものは、n8n にはありません。

強く推奨するデフォルト（例外は各スキルに記載）

• Code ノードは最後の手段です。 まずエクスプレッションを使い、次に Edit Fields 内のアロー関数を使い、その後に Code を使ってください。複数のソースの集約、ライブラリ、ステートフルな処理には Code を使う価値があります。n8n-code-nodes を参照してください。
• 再利用可能なものはすべて、ステートレスなサブワークフローにしてください。 作成する前に、search_workflows({ tags: ['subworkflow'] }) を使って既存のサブワークフローを検索してください。n8n-subworkflows を参照してください。

危険信号：思い浮かんだら作業を止めてスキルを呼び出すべき考え

こうした自己正当化によって、スキルが使われなくなります。次のいずれかを考えていることに気づいたら、セッション中に「すでに読んだ」ことがあっても、Skill ツールで該当するスキルを呼び出してください。

考え	アクション
「このワークフローは簡単だから、そのまま作ればいい」	n8n-workflow-lifecycle を呼び出してください。公開する頃には、ほとんどの「簡単な」ワークフローでもノードが10個以上になります。
「ここに Set ノードを追加して、これらのフィールドをマッピングしよう」	n8n-expressions を呼び出してください。下流のコンシューマーが0個または1個だけの Set ノードは、このパック全体で最もよく見られるアンチパターンです。
「Code ノードを使えば簡単だから、そうしよう」	n8n-code-nodes を呼び出してください。基準は厳しく設定されています。Code を使いたくなる場面のほとんどは、式またはアロー関数を使った Edit Fields で対応できます。
「検証に合格した。公開の準備はできた」	n8n-workflow-lifecycle を呼び出し、VALIDATION_CHECKLIST.md のセクション2（アンチパターンのチェック）を確認してください。検証に合格することは必要ですが、それだけでは十分ではありません。
「エージェントは接続できたし、ツールの説明も問題なさそうだ」	n8n-agents の references/TOOLS.md を呼び出してください。ツール名と説明はプロンプトの一部であり、「問題なさそう」という場合、たいていは汎用的すぎます。
「このサブワークフローのトリガーは passthrough にしよう」	n8n-subworkflows を呼び出してください。passthrough が適切なのは、バイナリを受け取るもののエージェントのツールにはならないサブワークフロー、または入力を実際に必要としないサブワークフローのみです（Define Below では少なくとも1つのフィールドが必要です）。
「バイナリを扱えるように passthrough を使って、受け取った入力形式に応じて内部で分岐させよう」	n8n-subworkflows の references/SUBWORKFLOW_PATTERNS.md にある「入力形式による分割」を呼び出してください。これは、共通の下流サブワークフローを共有する2つの外側のサブワークフロー（1つは Define Below、もう1つは passthrough）に分割すべきという合図です。1つのトリガーで passthrough と Define Below を両立させようとしないでください。
「このセクションは大きいから、サブワークフローに切り出そう」	キャンバスを整えることだけが目的で（再利用、分離、テストが目的ではない場合）、ノードグループのほうが軽く、速く、シンプルです。インラインのままにして、setNodeGroups でグループ化してください。再利用、分離、またはエージェントのツールとして必要な場合にのみ、サブワークフローに切り出してください。Readability は n8n-workflow-lifecycle を参照してください。
「ユーザーに認証情報の名前を尋ねよう」	尋ねないでください。newCredential('Label') の文字列は表示上の名前にすぎません。n8n-credentials-and-security を参照してください。
「ユーザーがデータ分析に言及したから、Python で書こう」	n8n-code-nodes を呼び出してください。デフォルトは JavaScript です。Python を使うのは明示的に依頼された場合のみです。
「ここに Loop Over Items を追加して、各行を処理しよう」	n8n-loops を呼び出してください。通常はアイテムごとの反復処理で対応できるため、Loop Over Items ノードは不要です。
「日付の計算には DateTime ノードを使おう」	n8n-expressions を呼び出してください。DateTime ノードが適切なケースは、ほとんどありません。
「これを3つのソースとの Merge でまとめよう」	n8n-node-configuration の references/MERGE_NODE.md を呼び出してください。Merge のデフォルトは入力2つです。ソースが3つ以上の場合は、numberOfInputs を明示的に設定する必要があります。
「この3つの時間のかかるステップを並列実行できるように分岐しよう」	n8n-workflow-lifecycle を呼び出し、Execution model のセクションを読んでください。n8n は分岐したブランチを同時ではなく、Y座標の上から下へ順番に実行します。実際に並列実行するには、n8n-loops と n8n-subworkflows（mode: 'each' と waitForSubWorkflow: false）を参照してください。
「ユーザーがどのプロジェクトかを言ったから、そのまま作ろう」	n8n-workflow-lifecycle を呼び出してください。プロジェクトとフォルダーは別物です。作成する前に、フォルダーの配置先を尋ねてください。MCP ではフォルダーを作成できないため、指定されたフォルダーが存在しない場合は、ユーザーが先に UI で作成する必要があります。
「test_workflow を実行して、どうなるか見てみよう」	n8n-workflow-lifecycle の references/TESTING.md を呼び出してください。test_workflow がモックするのはトリガーのみです。Slack への送信、DB への書き込み、決済などはすべて実際に実行されます。下流の処理に副作用がある場合は、先にユーザーに確認してください。

メタスキル（このドキュメント）が教えるのは、どのスキルが該当するかです。実際のルールは Skill ツールで読み込みます。 セッション開始時にメタスキルを一度読むだけでは、判断するタイミングでスキルを呼び出したことにはなりません。

スキル一覧

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

スキル	トリガー
n8n-workflow-lifecycle	ワークフローの開始、設計、整理、または完了時。スティッキーノートの規約、理由を記録する説明、命名、検証チェックリスト、フォルダーの制限、ワークフローごとの MCP アクセスに関する注意点を扱います
n8n-subworkflows	再利用可能なもの、複数ステップの構築、またはユーザーが再利用について言及した場合。構築前の検索、ステートレスなパターン、タグベースの検出規約
n8n-extending-mcp	MCP に標準搭載されていない機能が必要な場合。ユーザーの許可を得て、n8n API をワークフローツールとしてラップします
n8n-expressions	{{}}、$json、$node の記述、式のエラー。日付には Luxon、複数行の式はインデントし、ノードを追加するより式を優先します
n8n-node-configuration	任意のノードの設定時。操作に応じた設定、プロパティの依存関係、パラメーターを決めつけないこと
n8n-code-nodes	ユーザーが Code ノードを使おうとしている場合、またはカスタムロジックが必要な場合。判断フロー、本当に必要な場合の JavaScript パターン
n8n-loops	複数アイテムのデータ、バッチ処理、ページネーション対応 API、「それぞれに対して」または「ループ」の言及。デフォルトはアイテムごとの反復、executeOnce、Loop Over Items、HTTP のページネーション
n8n-agents	LangChain Agent ノード、ツール呼び出し、システムプロンプト、構造化出力、メモリ、RAG。プロンプトの一部としてのツール名と説明、ツールとしてのサブワークフロー、モジュール式のプロンプト設計
n8n-error-handling	Webhook 起点または本番環境向けのワークフロー。エラーが発生しうる各ノードにエラーブランチを設け、呼び出し元のエラーには 4xx、実行エラーには 5xx を使用します
n8n-credentials-and-security	認証、API キー、またはトークンについて言及があった場合。認証情報システム、カスタム認証情報、公式認証情報を使った HTTP Request
n8n-binary-and-data	ファイル、画像、添付ファイル。バイナリ処理パターン、エージェントとツールの境界、チャット画面に必要な CDN
n8n-data-tables	Data Tables：スキーマ、デフォルト列（id/createdAt/updatedAt）、外部キーを使わないリレーショナル設計、重複排除、JSON のプリミティブのみを許可しないルール、SDK と UI の手動マッピングに関する注意点
n8n-debugging	エラー、予期しない動作、「動作しない」といった場合。ユーザーの状況を尊重し、パラメーターを確認して、GitHub から n8n のソースを取得します

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

MCP はトークンを節約するため、ツールの説明を省略します。以下は、最初のターンからすべてのツールを把握できるようにする簡易リストです。

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

ワークフロー管理

ツール	機能
search_workflows	query（名前または説明の部分一致）や tags（タグ名の完全一致。AND 条件：すべてのタグを持つ必要があります）でインスタンス内のワークフローを検索します。ワークフロー横断の主要な検出ツールです。既存のものを見つけるために使用します。
get_workflow_details	ID でワークフローの完全な JSON を取得します。作成または更新のたびに、接続を確認するために使用します。
search_folders	フォルダーを一覧表示します。**フォルダーの作成や移動はできません。**既存のフォルダーにのみワークフローを配置できます。
search_projects	プロジェクトを一覧表示します。
list_tags	すべてのワークフロータグを（タグごとの usageCount とともに）一覧表示します。タグ付けやフィルタリングの前に、インスタンスで使われているタグ名を確認し、正確な名前を再利用してください。タグの追加・削除は update_workflow の addTags/removeTags で行います。タグの名前変更や削除を行うツールはありません。
archive_workflow / publish_workflow / unpublish_workflow	論理削除／有効化／無効化を行います。公開前に検証してください。publish_workflow では、特定のバージョンを再公開するための versionId を省略可能な引数として指定できます。
search_executions	インスタンス全体の実行履歴を検索します（ステータス、ワークフロー、期間で絞り込み可能）。「最近の実行を一覧表示」や「過去 1 時間の失敗」を調べる際に使用します。個別の実行には get_execution を使用します。

ワークフローの構築

ツール	説明
get_sdk_reference	n8n Workflow SDK のリファレンスを取得します。ワークフローコードを記述する前に、必ず読んでください。 セクション：patterns、patterns_detailed、expressions、functions、rules、import、guidelines、design、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 を渡してください）。ID を推測で作成せず、ドロップダウンの値を確認するため、get_node_types の後に呼び出してください。
create_workflow_from_code	SDK コードからワークフローを保存します。1～2文の description を必ず含めてください。skillsUsed（以下を参照）を渡してください。
update_workflow	アトミック操作を適用します（最大100件。すべて成功するか、すべて失敗します）。ノード／接続の CRUD、setNodeCredential、setNodeSettings（ノードごとの onError／再試行／executeOnce）、setWorkflowSettings（errorWorkflow、タイムゾーン、callerPolicy、タイムアウト、データ保存ポリシー。n8n 2.29.0+）、setNodeGroups（キャンバス上のグループ化）、setWorkflowMetadata、addTags／removeTags（未登録の名前は自動作成）に対応しています。下書きとして保存されるため、公開するには publish_workflow が必要です。skillsUsed（以下を参照）を渡してください。
validate_node_config	ノード設定をスキーマのみで検証します（1回につき1～50件）。パラメーターごとのエラーを返し、グラフに関する余分な情報は含みません。反復やデバッグの補助として使用します。公開前のチェックには、引き続き validate_workflow が必要です。ai_tool サブノードには isToolNode: true を設定してください。
validate_workflow	作成または更新の前に、SDK コード全体を検証します。必要ですが、これだけでは不十分です。すべての接続上の問題（.to()、マージインデックスなど）を検出できるわけではありません。
list_credentials	アクセス可能な認証情報を一覧表示します（種類／プロジェクトなどで絞り込み可能）。メタデータのみを返し、シークレット値は決して返しません。setNodeCredential でバインドする前に ID を確認してください。

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

ツール	説明
prepare_test_pin_data	ピン留めが必要なノード（トリガー、認証情報を使用するノード、HTTP Request）の JSON Schema を返します（データは返しません）。サンプル値は自分で生成してください。
test_workflow	指定したピンデータを使って実行します。トリガー、認証情報を使用するノード、HTTP Request は自動的にピン留めされます。 Code、Edit Fields、If、Data Tables、Execute Command、ファイル操作、サブワークフロー呼び出しは実際に実行されます。自動的にピン留めされないノードに副作用がある場合は、実行前に確認してください。ピンデータは実行ごとにのみ適用され、実行ビューアーには視覚的に表示されません。そのため、呼び出し後にどのノードをピン留めしたかをユーザーに伝えてください。n8n-workflow-lifecycle の references/TESTING.md を参照してください。
execute_workflow	実際のトリガーを使って本番環境で実行します。先にエラー処理を設定してください。副作用に関するルールは test_workflow と同じです。executionMode で manual（下書き）と production（公開済み）を選択します。chat／form／webhook トリガーには構造化された inputs を指定します。実行 ID をすぐに返し、完了を待ちません。結果を取得するには get_execution をポーリングしてください。
get_execution	executionId と workflowId（両方必須）を指定して実行情報を取得します。デフォルトではメタデータのみを返します。ノードの入力／出力を取得するには、includeData: true を設定してください（必要に応じて nodeNames、truncateData も指定できます）。

データテーブル

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

ツール	内容
create_data_table	新しいデータテーブルを作成します。
search_data_tables	既存のデータテーブルを検索します。
rename_data_table / rename_data_table_column	名前を変更します。
add_data_table_column / delete_data_table_column	スキーマを変更します。
add_data_table_rows	行を追加します。

バージョン履歴

ツール	内容
get_workflow_history	ワークフローの保存済みバージョンを新しい順に一覧表示します（n8n 2.29.0+）。
get_workflow_version	versionId を指定して、過去のバージョンの全コンテンツを取得します。
restore_workflow_version	過去のバージョンを現在のドラフトに再適用します（新しい履歴エントリーが記録されます）。

プロトコルの手順

n8n に関するあらゆるタスクで：

1. 上記のインデックスから、該当するスキルを見極めます。複数のスキルにまたがるタスクの場合は、まず主要なスキルを見極め、必要に応じて他のスキルも選択します。
2. 最初の MCP 呼び出しの前に、Skill ツール経由でスキルを呼び出します。n8n MCP ツールを何も確認せずに呼び出してはいけません。
3. ワークフローコードを作成する前に、セッションごとに一度 SDK リファレンスを読みます（get_sdk_reference）。SDK の構造に関するミスを避ける最も効率的な方法です。
4. ノードを設定する前に、ノードタイプを取得します（get_node_types）。パラメーター名を推測すると、無効なワークフローが作成されることがあり、気づかないまま問題が生じる場合もあります。
5. 公開前に検証し、作成・更新後に確認します。検証でスキーマエラーを検出します。確認では、get_workflow_details でワークフローを取得し直し、検証では見つからない接続の問題を検出します。
6. 不一致に気づいたら、差異を明示します。ツールやパラメーターがスキルの説明と一致しない場合は、ユーザーに伝えてください。更新が必要な可能性があります。

使用したスキルの報告

create_workflow_from_code と update_workflow は、任意の skillsUsed: string[] を受け取ります。MCP 出力に対するプラグインの影響を n8n チームが測定できるよう、毎回これを渡してください。

• 内容： このワークフロー変更の準備中に呼び出したスキル。修飾された Skill ツール名を使用します（例：n8n-skills:using-n8n-skills、n8n-skills:n8n-workflow-lifecycle）。
• 対象期間： 最後に成功した作成・更新呼び出し以降に呼び出したスキル。呼び出しが成功するたびにリセットされます。
• 上限： 最大 50 件、各 128 文字まで。

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

監査、コードレビュー、「このワークフローをレビューして」「何が問題なの？」「このプロジェクトを監査して」といった依頼では、レビューチェックリスト n8n-workflow-lifecycle 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 スキル（references/MCP_ACCESS_PER_WORKFLOW.md）を参照してください。
• ユーザーの言うことは正しいです。何かが壊れていると言われたら、ワークフローが正しいと「分かっている」場合でも、ユーザーの言葉を信じてください。パラメーターを再確認し、github.com/n8n-io/n8n から n8n のソースを取得してロジックを追跡し、不足している関数の API ドキュメントを探してください。手順については n8n-debugging スキルを参照してください。
• 該当するスキルがなく、タスクが簡単でない場合は、推測する前に確認してください。
• これらのスキルには一定の見解が含まれていますが、n8n チームがベストプラクティスと考えるものです。ユーザーは SKILL.md を編集することで、どの見解も変更できます。このプラグインは単なる Markdown です。