Claude Skills for n8n: Workflow Review Templates

Claude skills for n8n are reusable instruction sets you activate before asking Claude to review a workflow. Each skill gives the session a clear scope: checking a new workflow before it runs, diagnosing one that has broken, or recording what changed after an edit. Tools like fenbs keep the approved skill text alongside workflow requirements and the decisions behind design choices, so every review starts from the same baseline.

n8n is a workflow automation tool that connects services, APIs and data transforms into a sequence of nodes. A workflow can route data through a dozen steps before it reaches its destination. A silent failure in one node can reach a customer before anyone notices. A focused review skill catches those problems at the design stage rather than at runtime.

What makes an effective workflow review skill

A useful review skill has one clear job. A skill that tries to check everything produces long answers that bury the real problem. One skill per review type is easier to maintain and faster to use. Keep each skill short enough to scan in under a minute. Test it against a workflow you already understand, then update it the first time it misses something important.

Separate the concern from the action. A pre-activation review asks whether the workflow is ready. A failure review asks what went wrong. Mixing those questions produces an answer that addresses neither fully. For larger workflows, split one review into data-shape checks and error-handling checks, and run them in sequence rather than in a single session.

Browse claude skills examples for patterns across other automation types, or read how to create a Claude skill for the setup steps in Claude.ai and Claude Code. The claude skills marketplace and claude skills files cover storing and sharing skills once they are written.

Skill 1: reviewing a new workflow before activation

Use this skill before you turn on a new workflow or deploy a significant change. It checks the trigger, each node's configuration, error routing, credentials, and what the workflow sends to its destination. Read the full n8n workflow documentation↗ (opens in a new tab) if you are uncertain what any field controls.

Review the n8n workflow I share below before activation.

Check:
1. Trigger: what starts the workflow, and whether the condition is narrow enough to avoid accidental runs.
2. Each node: the expected input shape, the output it produces, and whether a null or empty value from upstream would break it.
3. Credentials: which services each node connects to, and whether the correct credentials are configured for this environment.
4. Error handling: what happens when a node fails -- does the workflow stop, retry, or route to an error branch?
5. Output: what the workflow sends to its destination, and whether that shape matches what the destination expects.

For each problem you find, name the node, describe the issue, and say what to fix before activation.

Paste the n8n workflow JSON export or walk through each node with Claude after activating this skill. For complex workflows, run a separate pass for data shape and another for error paths rather than combining them in one session. The n8n expressions documentation↗ (opens in a new tab) is a useful reference when reviewing dynamic field values.

Skill 2: diagnosing a failing workflow

When a workflow stops producing correct results, this skill focuses the review on the execution log. Paste the error message and the relevant execution output after activating it. Keep the focus on the failure path rather than summarizing nodes that completed correctly.

I will share an n8n execution log and error output. Diagnose the failure.

For the failing execution:
1. Identify the first node that produced an unexpected result or error.
2. Describe what the node received, what it tried to do, and what went wrong.
3. Determine whether the problem is a data-shape mismatch, a credential or permission issue, a rate limit, or a logic error in the workflow design.
4. State what to fix and which part of the workflow to change.
5. If the root cause is upstream of the failing node, trace it back to where the bad data or missing value entered the workflow.

Focus only on the failure path. Do not describe nodes that completed correctly.

Share the full execution log for the failed run, not a summary. Include any HTTP response bodies if the failing node makes an external call. The more specific the output you paste, the more precise the diagnosis Claude can offer. Use the n8n execution log view to copy the full node output for each step.

Skill 3: documenting a workflow change

After editing a workflow, this skill produces a short change record. Describe what you changed or paste before-and-after versions of the affected nodes. Save the output as a note attached to the workflow's requirements so the next review knows what was modified and why.

I will describe a change I made to an n8n workflow. Write a brief change record.

Include:
1. What changed: the node or connection that was modified, added or removed.
2. Why it changed: the problem it solved or the requirement it fulfills.
3. What to watch: any behavior that could be affected by the change that should be checked in the first few runs.
4. Decision: if the change reflects a design choice (a different error-handling approach, a new data format), state it clearly so future reviewers understand it was intentional.

Keep the record under 200 words.

A brief change record saves time the next time the workflow breaks or needs updating. It replaces the need to re-read the full workflow definition to understand what someone was trying to achieve. Link the record to the relevant task or decision in your project notes.

Adapting these skills for your setup

These templates are starting points. Add a check for any class of problem your team has seen more than once. If your workflows regularly pull from a specific API with known rate limits, add that as a named check in the pre-activation skill. If your error branches send alerts to a specific service, include a check for whether that service is configured correctly.

Update a skill when a review misses something it should have caught. Keep the previous version in a note so you know what the old skill covered. Record the reason for each update alongside the new skill text. Over time, the skill and its history become a practical guide to the failure modes your workflows have actually encountered.

How to do this with fenbs

Pair these skills with a shared record of workflow requirements and decisions so a review can check the workflow against what it was designed to do, not just whether it runs without an error.

1. Create a free account and add a project for your n8n automation work.
2. Add each workflow's requirements as a task: what it is meant to do, what services it connects, and what counts as a successful run.
3. Paste the pre-activation skill text into Skills and prompts in fenbs, with a clear name so any connected assistant can find and use it.
4. Record design decisions in Decisions and rules. When you choose a specific error-handling approach or data format, save the decision with the reason so future reviews have the context they need.
5. After each significant failure, add a lesson in Lessons learned: what failed, what the diagnosis found, and what the fix was. The next failure review will have a shorter list of things to check.

When a one-off prompt works better

A skill is worth saving when you run the same type of review more than once or share the review standard with a team. A single workflow you build once and never touch again does not need a reusable skill. A team managing many workflows across multiple environments, where failures cost real time, benefits from consistent review language. See claude projects vs skills vs artifacts for help choosing the right format.