菜单
Dynamic tier system for right-sizing n8n workflow hardening. Use this skill on ANY n8n workflow request to determine appropriate validation, logging, and error handling levels. Adapts to user needs — from quick prototypes to mission-critical production systems.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Write JavaScript code in n8n Code nodes. Use when writing JavaScript in n8n, using $input/$json/$node syntax, making HTTP requests with $helpers, working with dates using DateTime, troubleshooting Code node errors, or choosing between Code node modes.
Write Python code in n8n Code nodes. Use when writing Python in n8n, using _input/_json/_node syntax, working with standard library, or need to understand Python limitations in n8n Code nodes.
Validate n8n expression syntax and fix common errors. Use when writing n8n expressions, using {{}} syntax, accessing $json/$node variables, troubleshooting expression errors, or working with webhook data in workflows.
Expert guide for using n8n-mcp MCP tools effectively. Use when searching for nodes, validating configurations, accessing templates, managing workflows, or using any n8n-mcp tool. Provides tool selection guidance, parameter formats, and common patterns.
Operation-aware node configuration guidance. Use when configuring nodes, understanding property dependencies, determining required fields, choosing between get_node_essentials and get_node_info, or learning common configuration patterns by node type.
Interpret validation errors and guide fixing them. Use when encountering validation errors, validation warnings, false positives, operator structure issues, or need help understanding validation results. Also use when asking about validation profiles, error types, or the validation loop process.
| name | n8n-production-readiness |
| description | Dynamic tier system for right-sizing n8n workflow hardening. Use this skill on ANY n8n workflow request to determine appropriate validation, logging, and error handling levels. Adapts to user needs — from quick prototypes to mission-critical production systems. |
Match workflow hardening to actual risk. Not every workflow needs the same rigor.
"The workflow you build locally... that's maybe 20% of what you actually need. The other 80% is security, validation, logging, and error handling."
The tier system adapts to the user. Some users want to specify a tier, others just want to build. Support both modes while always being ready to recommend changes based on what you observe.
After the user's first message about an n8n workflow, ask once to establish the tier — but make it easy to skip:
"Quick question before we dive in — what level of hardening does this workflow need?
- Tier 1 (Internal/Prototype): Quick and simple. Basic error handling, minimal setup.
- Tier 2 (Production): Client-facing or business-critical. Full validation, logging, proper error responses.
- Tier 3 (Mission-Critical): Payments, compliance, high-volume. Everything plus monitoring, rollback plans, idempotency.
Or just say 'autopilot' and I'll figure it out as we go based on what you're building."
If the user picks a tier: Build to that tier. Respect their choice, but still monitor for signals that suggest they need to adjust (see Tier Change Recommendations below).
If the user says "autopilot" or skips the question: Infer the tier silently from context and adapt as you go. Don't mention tiers again unless recommending a change.
If the user doesn't respond to the tier question: Assume autopilot mode and proceed.
If a user explicitly asks for a tier (now or later in the conversation):
Users who understand tiers get full control. Don't second-guess them on every decision — but still flag concerns if you observe serious issues.
If a user asks to see the tiers, explain them, or wants to understand the differences, provide the full breakdown:
Tier 1 (Internal/Prototype)
- Basic null checks, simple try-catch
- n8n's built-in error handling
- ~10% extra build time
- Example: Slack notifications, personal automations
Tier 2 (Production)
- Full input validation at entry point
- External logging (Supabase/Postgres)
- Proper HTTP status codes (400, 401, 404, 500)
- Error notifications to team
- Pre-deployment breaking tests
- ~80% extra build time
- Example: Client form handlers, business integrations
Tier 3 (Mission-Critical)
- Everything in Tier 2, plus:
- Monitoring dashboards, alerting (PagerDuty)
- Idempotency keys, rate limiting
- Rollback strategy, audit logging
- 2-3x build time
- Example: Payment processing, HIPAA compliance
When in autopilot (or if the user skipped tier selection), infer the tier from context clues:
| Context Clues | Internal Tier | Your Approach |
|---|---|---|
| "quick", "test", "just for me", "internal", "prototype", "playing around" | Tier 1 | Build fast, basic error handling only |
| "client", "customer", "users", "production", "deploy", "business", "launch" | Tier 2 | Include validation, logging, status codes |
| "payment", "Stripe", "checkout", "HIPAA", "compliance", "SLA", "enterprise", "high volume", "can't fail" | Tier 3 | Full hardening + discuss monitoring/ops |
| Ambiguous or no clear signals | Tier 1 | Start simple, monitor for escalation triggers |
In autopilot mode, don't announce the tier. Just build appropriately and intervene if a tier change is needed.
Whether the user picked a tier or is in autopilot, monitor the conversation and recommend tier changes in either direction when the task and outcome warrant it.
Troubleshooting is going in circles:
→ Recommend: "We're spending a lot of time guessing. I'd recommend adding logging so we can see exactly what data is coming in and where it's failing. This is a Tier 2 pattern — want me to add it?"
Silent or unclear failures:
→ Recommend: "The workflow is failing silently, which makes this hard to diagnose. I'd suggest adding entry-point validation and external logging — that way we'll see exactly what's coming in and where it breaks. Want me to upgrade this to Tier 2 patterns?"
User mentions deployment or sharing:
→ Recommend: "Since this is going to production, I'd recommend hardening it first — input validation, proper error responses, and logging. It's the difference between 'works on my machine' and 'survives in the wild.' Should I add Tier 2 patterns?"
The "null vs empty string" pattern:
→ Recommend: "This looks like a data shape issue — probably null values or missing fields slipping through. Tier 2 validation would catch this at the entry point. Want me to add it?"
Scale or volume concerns:
→ Recommend: "At that volume, you'll want Tier 3 patterns — rate limiting, idempotency handling for duplicate requests, and queue-based processing for traffic spikes. Want me to walk through what that looks like?"
Reliability concerns:
→ Recommend: "For that level of reliability, I'd recommend Tier 3 — monitoring so you know when something's wrong before users tell you, intelligent retries, and a rollback plan. Should we upgrade?"
Financial or compliance context:
→ Recommend: "Since this handles [payments/sensitive data], I'd strongly recommend Tier 3 patterns — idempotency keys so duplicate requests don't double-charge, audit logging for compliance, and error handling that doesn't expose sensitive data. This is important — want me to add it?"
Over-engineered for actual use case:
→ Recommend: "Looking at this more, I think we might be over-engineering. If you're not dealing with high volume or strict compliance requirements, we could drop to Tier 2 — still production-ready, but without the monitoring and idempotency overhead. Would that be simpler for your needs?"
User wants to ship faster:
→ Recommend: "We've been building this with full Tier 3 hardening, but it's slowing us down. Want to drop to Tier 2 for now and add the monitoring/idempotency later once the core logic is stable?"
It's actually just a prototype:
→ Recommend: "If this is just for testing the concept, we don't need all this validation and logging yet. Want me to simplify to Tier 1? We can always add the production hardening later once you're happy with the logic."
Complexity is blocking progress:
→ Recommend: "I think we're getting bogged down in the production hardening before the core workflow is even working. Let's drop to Tier 1, get the basic flow working, and then add validation and logging once we know the logic is right. Sound good?"
Scope changed:
→ Recommend: "Since this is actually just for internal use, we don't need the full Tier 2 treatment. Want me to strip out the external logging and simplify the error handling? It'll be easier to maintain."
Don't recommend moving up if:
Don't recommend moving down if:
Trust user judgment, but flag concerns:
"I know you want to keep this at Tier 1, and that's fine for now — just know that once this goes to production, you'll probably want to add logging at minimum. I can help with that when you're ready."
When suggesting tier changes, be direct but not pushy:
If the user explicitly chose a tier and you're recommending a change:
"I know you said Tier 1, but we've been debugging this for a while and I think Tier 2 logging would save us time here. Up to you — want me to add it, or keep it simple?"
If in autopilot mode:
"I'm going to add some validation and logging here — we're hitting the kind of silent failures that these patterns are designed to catch. This'll take a few extra minutes but should make debugging much faster."
Adjust your approach based on where the user is in the workflow lifecycle:
| Lifecycle Stage | How to Detect | Your Approach |
|---|---|---|
| Exploring/Prototyping | "trying to figure out", "is this possible?", "how would I..." | Tier 1. Fast, minimal. Get it working first. |
| Building | "build me", "create", "I need a workflow that..." | Ask tier or infer from context. |
| Testing | "let me test", "trying it out", "it works but..." | Stay at current tier. Focus on the specific issue. |
| Debugging | "not working", "error", "broken", "help" | Monitor for escalation triggers. Recommend logging if stuck. |
| Pre-deployment | "ready to deploy", "going live", "production" | Recommend Tier 2 minimum if not already there. |
| Post-deployment issues | "was working, now broken", "users are reporting", "in production" | Tier 2+. Recommend logging immediately to diagnose. |
| Scaling | "more users", "growing", "volume increasing" | Discuss Tier 3 patterns as relevant. |
Context signals: "quick", "simple", "just for me", "internal", "prototype", "test", "playing around"
What to include:
|| {}, || '')What to skip:
Example workflows: "New GitHub issue → Slack notification", "Daily weather → personal email", "RSS feed → Discord"
Build time impact: ~10% extra beyond core logic
Context signals: "client", "customer", "production", "deploy", "users will...", "business", "launch", "going live"
Escalation triggers: Debugging going in circles, silent failures, user mentions deployment, "works sometimes" issues
What to include:
What to skip:
Example workflows: "Customer form → CRM + email sequence", "Payment webhook → order fulfillment", "AI chatbot for client website"
Build time impact: ~80% extra beyond core logic (the 80/20 rule)
Context signals: "payment", "Stripe", "checkout", "HIPAA", "compliance", "SLA", "enterprise", "high volume", "can't fail", "audit"
Escalation triggers: Volume/performance questions, "what if X goes down?", financial transactions, compliance mentions
What to include:
Example workflows: "Stripe payment → inventory + fulfillment + accounting", "HIPAA-compliant patient data sync", "High-traffic API gateway"
Build time impact: 2-3x the core logic development time
You've outgrown Tier 1 when:
You've outgrown Tier 2 when:
Downgrade is okay too:
| Component | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Core logic | 70% | 20% | 10% |
| Validation | 10% | 20% | 15% |
| Error handling | 10% | 20% | 20% |
| Logging | 5% | 20% | 20% |
| Testing | 5% | 20% | 15% |
| Monitoring/Ops | — | — | 20% |
The workflow logic is the easy part. The hard part is everything else — but only invest in "everything else" proportional to your risk.
null vs empty string vs undefinedThe goal: Users who know tiers get control. Users who don't get invisible guidance. The AI adapts to the user, the task, and the project — recommending more hardening when complexity demands it, and simplification when it's getting in the way.
For implementation patterns, see:
"Learn this stuff before your first emergency call. I've broken enough things to have most of the answers now."