📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "antigravity-bundle-aas-automation-builder",
|
||||
"version": "12.9.0",
|
||||
"version": "13.0.0",
|
||||
"description": "Editorial \"AAS Automation Builder\" bundle for Claude Code from Antigravity Awesome Skills.",
|
||||
"author": {
|
||||
"name": "sickn33 and contributors",
|
||||
|
||||
+10
-5
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "agyb-aas-automation-builder",
|
||||
"version": "12.9.0",
|
||||
"description": "Install the \"AAS Automation Builder\" editorial skill bundle from Antigravity Awesome Skills.",
|
||||
"version": "13.0.0",
|
||||
"description": "Install the \"AAS Automation Builder\" workflow plugin from Antigravity Awesome Skills.",
|
||||
"author": {
|
||||
"name": "sickn33 and contributors",
|
||||
"url": "https://github.com/sickn33/antigravity-awesome-skills"
|
||||
@@ -19,8 +19,8 @@
|
||||
"skills": "./skills/",
|
||||
"interface": {
|
||||
"displayName": "AAS Automation Builder",
|
||||
"shortDescription": "Specialized Product Plugins - Next Wave · 8 curated skills",
|
||||
"longDescription": "Teams designing reliable automations across tools, data stores, and communication platforms. Covers Workflow Automation, MCP Builder, and 6 more skills.",
|
||||
"shortDescription": "Design reliable automations across apps, MCP tools, Make/Zapier, Airtable, Notion, Slack, Sheets, GitHub, and n8n.",
|
||||
"longDescription": "Design reliable automations across apps, MCP tools, Make/Zapier, Airtable, Notion, Slack, Sheets, GitHub, and n8n. Works best as a plugin because app connectors and MCP configuration can turn instructions into live workflows. Recommended for: Ops teams, Automation builders, Teams connecting SaaS workflows. Not for: One-off copywriting tasks, Deep infrastructure provisioning. Covers Workflow Automation, MCP Builder, and 8 more skills.",
|
||||
"developerName": "sickn33 and contributors",
|
||||
"category": "Specialized Product Plugins - Next Wave",
|
||||
"capabilities": [
|
||||
@@ -28,6 +28,11 @@
|
||||
"Write"
|
||||
],
|
||||
"websiteURL": "https://github.com/sickn33/antigravity-awesome-skills",
|
||||
"brandColor": "#111827"
|
||||
"brandColor": "#111827",
|
||||
"defaultPrompt": [
|
||||
"Use this plugin to map this manual workflow into a reliable automation with failure handling.",
|
||||
"Use this plugin to design an MCP-backed automation and the tool schemas it needs.",
|
||||
"Use this plugin to review this automation for idempotency, permissions, expressions, and observability gaps."
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
+528
@@ -0,0 +1,528 @@
|
||||
---
|
||||
name: n8n-expression-syntax
|
||||
description: 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.
|
||||
risk: unknown
|
||||
source: community
|
||||
---
|
||||
|
||||
# n8n Expression Syntax
|
||||
|
||||
Expert guide for writing correct n8n expressions in workflows.
|
||||
|
||||
## When to Use
|
||||
- You need to write or debug n8n expressions using `{{ ... }}` syntax.
|
||||
- The task involves `$json`, `$node`, webhook payloads, or expression-related workflow errors.
|
||||
- You want syntax-correct dynamic values inside n8n nodes and parameters.
|
||||
|
||||
---
|
||||
|
||||
## Expression Format
|
||||
|
||||
All dynamic content in n8n uses **double curly braces**:
|
||||
|
||||
```
|
||||
{{expression}}
|
||||
```
|
||||
|
||||
**Examples**:
|
||||
```
|
||||
✅ {{$json.email}}
|
||||
✅ {{$json.body.name}}
|
||||
✅ {{$node["HTTP Request"].json.data}}
|
||||
❌ $json.email (no braces - treated as literal text)
|
||||
❌ {$json.email} (single braces - invalid)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Core Variables
|
||||
|
||||
### $json - Current Node Output
|
||||
|
||||
Access data from the current node:
|
||||
|
||||
```javascript
|
||||
{{$json.fieldName}}
|
||||
{{$json['field with spaces']}}
|
||||
{{$json.nested.property}}
|
||||
{{$json.items[0].name}}
|
||||
```
|
||||
|
||||
### $node - Reference Other Nodes
|
||||
|
||||
Access data from any previous node:
|
||||
|
||||
```javascript
|
||||
{{$node["Node Name"].json.fieldName}}
|
||||
{{$node["HTTP Request"].json.data}}
|
||||
{{$node["Webhook"].json.body.email}}
|
||||
```
|
||||
|
||||
**Important**:
|
||||
- Node names **must** be in quotes
|
||||
- Node names are **case-sensitive**
|
||||
- Must match exact node name from workflow
|
||||
|
||||
### $now - Current Timestamp
|
||||
|
||||
Access current date/time:
|
||||
|
||||
```javascript
|
||||
{{$now}}
|
||||
{{$now.toFormat('yyyy-MM-dd')}}
|
||||
{{$now.toFormat('HH:mm:ss')}}
|
||||
{{$now.plus({days: 7})}}
|
||||
```
|
||||
|
||||
### $env - Environment Variables
|
||||
|
||||
Access environment variables:
|
||||
|
||||
```javascript
|
||||
{{$env.API_KEY}}
|
||||
{{$env.DATABASE_URL}}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚨 CRITICAL: Webhook Data Structure
|
||||
|
||||
**Most Common Mistake**: Webhook data is **NOT** at the root!
|
||||
|
||||
### Webhook Node Output Structure
|
||||
|
||||
```javascript
|
||||
{
|
||||
"headers": {...},
|
||||
"params": {...},
|
||||
"query": {...},
|
||||
"body": { // ⚠️ USER DATA IS HERE!
|
||||
"name": "John",
|
||||
"email": "john@example.com",
|
||||
"message": "Hello"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Correct Webhook Data Access
|
||||
|
||||
```javascript
|
||||
❌ WRONG: {{$json.name}}
|
||||
❌ WRONG: {{$json.email}}
|
||||
|
||||
✅ CORRECT: {{$json.body.name}}
|
||||
✅ CORRECT: {{$json.body.email}}
|
||||
✅ CORRECT: {{$json.body.message}}
|
||||
```
|
||||
|
||||
**Why**: Webhook node wraps incoming data under `.body` property to preserve headers, params, and query parameters.
|
||||
|
||||
---
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### Access Nested Fields
|
||||
|
||||
```javascript
|
||||
// Simple nesting
|
||||
{{$json.user.email}}
|
||||
|
||||
// Array access
|
||||
{{$json.data[0].name}}
|
||||
{{$json.items[0].id}}
|
||||
|
||||
// Bracket notation for spaces
|
||||
{{$json['field name']}}
|
||||
{{$json['user data']['first name']}}
|
||||
```
|
||||
|
||||
### Reference Other Nodes
|
||||
|
||||
```javascript
|
||||
// Node without spaces
|
||||
{{$node["Set"].json.value}}
|
||||
|
||||
// Node with spaces (common!)
|
||||
{{$node["HTTP Request"].json.data}}
|
||||
{{$node["Respond to Webhook"].json.message}}
|
||||
|
||||
// Webhook node
|
||||
{{$node["Webhook"].json.body.email}}
|
||||
```
|
||||
|
||||
### Combine Variables
|
||||
|
||||
```javascript
|
||||
// Concatenation (automatic)
|
||||
Hello {{$json.body.name}}!
|
||||
|
||||
// In URLs
|
||||
https://api.example.com/users/{{$json.body.user_id}}
|
||||
|
||||
// In object properties
|
||||
{
|
||||
"name": "={{$json.body.name}}",
|
||||
"email": "={{$json.body.email}}"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## When NOT to Use Expressions
|
||||
|
||||
### ❌ Code Nodes
|
||||
|
||||
Code nodes use **direct JavaScript access**, NOT expressions!
|
||||
|
||||
```javascript
|
||||
// ❌ WRONG in Code node
|
||||
const email = '={{$json.email}}';
|
||||
const name = '{{$json.body.name}}';
|
||||
|
||||
// ✅ CORRECT in Code node
|
||||
const email = $json.email;
|
||||
const name = $json.body.name;
|
||||
|
||||
// Or using Code node API
|
||||
const email = $input.item.json.email;
|
||||
const allItems = $input.all();
|
||||
```
|
||||
|
||||
### ❌ Webhook Paths
|
||||
|
||||
```javascript
|
||||
// ❌ WRONG
|
||||
path: "{{$json.user_id}}/webhook"
|
||||
|
||||
// ✅ CORRECT
|
||||
path: "user-webhook" // Static paths only
|
||||
```
|
||||
|
||||
### ❌ Credential Fields
|
||||
|
||||
```javascript
|
||||
// ❌ WRONG
|
||||
apiKey: "={{$env.API_KEY}}"
|
||||
|
||||
// ✅ CORRECT
|
||||
Use n8n credential system, not expressions
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validation Rules
|
||||
|
||||
### 1. Always Use {{}}
|
||||
|
||||
Expressions **must** be wrapped in double curly braces.
|
||||
|
||||
```javascript
|
||||
❌ $json.field
|
||||
✅ {{$json.field}}
|
||||
```
|
||||
|
||||
### 2. Use Quotes for Spaces
|
||||
|
||||
Field or node names with spaces require **bracket notation**:
|
||||
|
||||
```javascript
|
||||
❌ {{$json.field name}}
|
||||
✅ {{$json['field name']}}
|
||||
|
||||
❌ {{$node.HTTP Request.json}}
|
||||
✅ {{$node["HTTP Request"].json}}
|
||||
```
|
||||
|
||||
### 3. Match Exact Node Names
|
||||
|
||||
Node references are **case-sensitive**:
|
||||
|
||||
```javascript
|
||||
❌ {{$node["http request"].json}} // lowercase
|
||||
❌ {{$node["Http Request"].json}} // wrong case
|
||||
✅ {{$node["HTTP Request"].json}} // exact match
|
||||
```
|
||||
|
||||
### 4. No Nested {{}}
|
||||
|
||||
Don't double-wrap expressions:
|
||||
|
||||
```javascript
|
||||
❌ {{{$json.field}}}
|
||||
✅ {{$json.field}}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
For complete error catalog with fixes, see COMMON_MISTAKES.md
|
||||
|
||||
### Quick Fixes
|
||||
|
||||
| Mistake | Fix |
|
||||
|---------|-----|
|
||||
| `$json.field` | `{{$json.field}}` |
|
||||
| `{{$json.field name}}` | `{{$json['field name']}}` |
|
||||
| `{{$node.HTTP Request}}` | `{{$node["HTTP Request"]}}` |
|
||||
| `{{{$json.field}}}` | `{{$json.field}}` |
|
||||
| `{{$json.name}}` (webhook) | `{{$json.body.name}}` |
|
||||
| `'={{$json.email}}'` (Code node) | `$json.email` |
|
||||
|
||||
---
|
||||
|
||||
## Working Examples
|
||||
|
||||
For real workflow examples, see EXAMPLES.md
|
||||
|
||||
### Example 1: Webhook to Slack
|
||||
|
||||
**Webhook receives**:
|
||||
```json
|
||||
{
|
||||
"body": {
|
||||
"name": "John Doe",
|
||||
"email": "john@example.com",
|
||||
"message": "Hello!"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**In Slack node text field**:
|
||||
```
|
||||
New form submission!
|
||||
|
||||
Name: {{$json.body.name}}
|
||||
Email: {{$json.body.email}}
|
||||
Message: {{$json.body.message}}
|
||||
```
|
||||
|
||||
### Example 2: HTTP Request to Email
|
||||
|
||||
**HTTP Request returns**:
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"items": [
|
||||
{"name": "Product 1", "price": 29.99}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**In Email node** (reference HTTP Request):
|
||||
```
|
||||
Product: {{$node["HTTP Request"].json.data.items[0].name}}
|
||||
Price: ${{$node["HTTP Request"].json.data.items[0].price}}
|
||||
```
|
||||
|
||||
### Example 3: Format Timestamp
|
||||
|
||||
```javascript
|
||||
// Current date
|
||||
{{$now.toFormat('yyyy-MM-dd')}}
|
||||
// Result: 2025-10-20
|
||||
|
||||
// Time
|
||||
{{$now.toFormat('HH:mm:ss')}}
|
||||
// Result: 14:30:45
|
||||
|
||||
// Full datetime
|
||||
{{$now.toFormat('yyyy-MM-dd HH:mm')}}
|
||||
// Result: 2025-10-20 14:30
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data Type Handling
|
||||
|
||||
### Arrays
|
||||
|
||||
```javascript
|
||||
// First item
|
||||
{{$json.users[0].email}}
|
||||
|
||||
// Array length
|
||||
{{$json.users.length}}
|
||||
|
||||
// Last item
|
||||
{{$json.users[$json.users.length - 1].name}}
|
||||
```
|
||||
|
||||
### Objects
|
||||
|
||||
```javascript
|
||||
// Dot notation (no spaces)
|
||||
{{$json.user.email}}
|
||||
|
||||
// Bracket notation (with spaces or dynamic)
|
||||
{{$json['user data'].email}}
|
||||
```
|
||||
|
||||
### Strings
|
||||
|
||||
```javascript
|
||||
// Concatenation (automatic)
|
||||
Hello {{$json.name}}!
|
||||
|
||||
// String methods
|
||||
{{$json.email.toLowerCase()}}
|
||||
{{$json.name.toUpperCase()}}
|
||||
```
|
||||
|
||||
### Numbers
|
||||
|
||||
```javascript
|
||||
// Direct use
|
||||
{{$json.price}}
|
||||
|
||||
// Math operations
|
||||
{{$json.price * 1.1}} // Add 10%
|
||||
{{$json.quantity + 5}}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Advanced Patterns
|
||||
|
||||
### Conditional Content
|
||||
|
||||
```javascript
|
||||
// Ternary operator
|
||||
{{$json.status === 'active' ? 'Active User' : 'Inactive User'}}
|
||||
|
||||
// Default values
|
||||
{{$json.email || 'no-email@example.com'}}
|
||||
```
|
||||
|
||||
### Date Manipulation
|
||||
|
||||
```javascript
|
||||
// Add days
|
||||
{{$now.plus({days: 7}).toFormat('yyyy-MM-dd')}}
|
||||
|
||||
// Subtract hours
|
||||
{{$now.minus({hours: 24}).toISO()}}
|
||||
|
||||
// Set specific date
|
||||
{{DateTime.fromISO('2025-12-25').toFormat('MMMM dd, yyyy')}}
|
||||
```
|
||||
|
||||
### String Manipulation
|
||||
|
||||
```javascript
|
||||
// Substring
|
||||
{{$json.email.substring(0, 5)}}
|
||||
|
||||
// Replace
|
||||
{{$json.message.replace('old', 'new')}}
|
||||
|
||||
// Split and join
|
||||
{{$json.tags.split(',').join(', ')}}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Debugging Expressions
|
||||
|
||||
### Test in Expression Editor
|
||||
|
||||
1. Click field with expression
|
||||
2. Open expression editor (click "fx" icon)
|
||||
3. See live preview of result
|
||||
4. Check for errors highlighted in red
|
||||
|
||||
### Common Error Messages
|
||||
|
||||
**"Cannot read property 'X' of undefined"**
|
||||
→ Parent object doesn't exist
|
||||
→ Check your data path
|
||||
|
||||
**"X is not a function"**
|
||||
→ Trying to call method on non-function
|
||||
→ Check variable type
|
||||
|
||||
**Expression shows as literal text**
|
||||
→ Missing {{ }}
|
||||
→ Add curly braces
|
||||
|
||||
---
|
||||
|
||||
## Expression Helpers
|
||||
|
||||
### Available Methods
|
||||
|
||||
**String**:
|
||||
- `.toLowerCase()`, `.toUpperCase()`
|
||||
- `.trim()`, `.replace()`, `.substring()`
|
||||
- `.split()`, `.includes()`
|
||||
|
||||
**Array**:
|
||||
- `.length`, `.map()`, `.filter()`
|
||||
- `.find()`, `.join()`, `.slice()`
|
||||
|
||||
**DateTime** (Luxon):
|
||||
- `.toFormat()`, `.toISO()`, `.toLocal()`
|
||||
- `.plus()`, `.minus()`, `.set()`
|
||||
|
||||
**Number**:
|
||||
- `.toFixed()`, `.toString()`
|
||||
- Math operations: `+`, `-`, `*`, `/`, `%`
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ✅ Do
|
||||
|
||||
- Always use {{ }} for dynamic content
|
||||
- Use bracket notation for field names with spaces
|
||||
- Reference webhook data from `.body`
|
||||
- Use $node for data from other nodes
|
||||
- Test expressions in expression editor
|
||||
|
||||
### ❌ Don't
|
||||
|
||||
- Don't use expressions in Code nodes
|
||||
- Don't forget quotes around node names with spaces
|
||||
- Don't double-wrap with extra {{ }}
|
||||
- Don't assume webhook data is at root (it's under .body!)
|
||||
- Don't use expressions in webhook paths or credentials
|
||||
|
||||
---
|
||||
|
||||
## Related Skills
|
||||
|
||||
- **n8n MCP Tools Expert**: Learn how to validate expressions using MCP tools
|
||||
- **n8n Workflow Patterns**: See expressions in real workflow examples
|
||||
- **n8n Node Configuration**: Understand when expressions are needed
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
**Essential Rules**:
|
||||
1. Wrap expressions in {{ }}
|
||||
2. Webhook data is under `.body`
|
||||
3. No {{ }} in Code nodes
|
||||
4. Quote node names with spaces
|
||||
5. Node names are case-sensitive
|
||||
|
||||
**Most Common Mistakes**:
|
||||
- Missing {{ }} → Add braces
|
||||
- `{{$json.name}}` in webhooks → Use `{{$json.body.name}}`
|
||||
- `{{$json.email}}` in Code → Use `$json.email`
|
||||
- `{{$node.HTTP Request}}` → Use `{{$node["HTTP Request"]}}`
|
||||
|
||||
For more details, see:
|
||||
- COMMON_MISTAKES.md - Complete error catalog
|
||||
- EXAMPLES.md - Real workflow examples
|
||||
|
||||
---
|
||||
|
||||
**Need Help?** Reference the n8n expression documentation or use n8n-mcp validation tools to check your expressions.
|
||||
|
||||
## Limitations
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
||||
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|
||||
+821
@@ -0,0 +1,821 @@
|
||||
---
|
||||
name: zapier-make-patterns
|
||||
description: No-code automation democratizes workflow building. Zapier and Make
|
||||
(formerly Integromat) let non-developers automate business processes without
|
||||
writing code. But no-code doesn't mean no-complexity - these platforms have
|
||||
their own patterns, pitfalls, and breaking points.
|
||||
risk: unknown
|
||||
source: vibeship-spawner-skills (Apache 2.0)
|
||||
date_added: 2026-02-27
|
||||
---
|
||||
|
||||
# Zapier & Make Patterns
|
||||
|
||||
No-code automation democratizes workflow building. Zapier and Make (formerly
|
||||
Integromat) let non-developers automate business processes without writing
|
||||
code. But no-code doesn't mean no-complexity - these platforms have their
|
||||
own patterns, pitfalls, and breaking points.
|
||||
|
||||
This skill covers when to use which platform, how to build reliable
|
||||
automations, and when to graduate to code-based solutions. Key insight:
|
||||
Zapier optimizes for simplicity and integrations (7000+ apps), Make
|
||||
optimizes for power and cost-efficiency (visual branching, operations-based
|
||||
pricing).
|
||||
|
||||
Critical distinction: No-code works until it doesn't. Know the limits.
|
||||
|
||||
## Principles
|
||||
|
||||
- Start simple, add complexity only when needed
|
||||
- Test with real data before going live
|
||||
- Document every automation with clear naming
|
||||
- Monitor errors - 95% error rate auto-disables Zaps
|
||||
- Know when to graduate to code-based solutions
|
||||
- Operations/tasks cost money - design efficiently
|
||||
|
||||
## Capabilities
|
||||
|
||||
- zapier
|
||||
- make
|
||||
- integromat
|
||||
- no-code-automation
|
||||
- zaps
|
||||
- scenarios
|
||||
- workflow-builders
|
||||
- business-process-automation
|
||||
|
||||
## Scope
|
||||
|
||||
- code-based-workflows → workflow-automation
|
||||
- browser-automation → browser-automation
|
||||
- custom-integrations → backend
|
||||
- api-development → api-designer
|
||||
|
||||
## Tooling
|
||||
|
||||
### Platforms
|
||||
|
||||
- Zapier - When: Simple automations, maximum app coverage, beginners Note: 7000+ integrations, linear workflows, task-based pricing
|
||||
- Make - When: Complex workflows, visual branching, budget-conscious Note: Visual scenarios, operations pricing, powerful data handling
|
||||
- n8n - When: Self-hosted, code-friendly, unlimited operations Note: Open-source, can add custom code, technical users
|
||||
|
||||
### Ai_features
|
||||
|
||||
- Zapier Agents - When: AI-powered autonomous automation Note: Natural language instructions, 7000+ app access
|
||||
- Zapier Copilot - When: Building Zaps with AI assistance Note: Describes workflow, AI builds it
|
||||
- Zapier MCP - When: LLM tools accessing Zapier actions Note: 30,000+ actions available to AI models
|
||||
|
||||
## Patterns
|
||||
|
||||
### Basic Trigger-Action Pattern
|
||||
|
||||
Single trigger leads to one or more actions
|
||||
|
||||
**When to use**: Simple notifications, data sync, basic workflows
|
||||
|
||||
# BASIC TRIGGER-ACTION:
|
||||
|
||||
"""
|
||||
[Trigger] → [Action]
|
||||
e.g., New Email → Create Task
|
||||
"""
|
||||
|
||||
## Zapier Example
|
||||
"""
|
||||
Zap Name: "Gmail New Email → Todoist Task"
|
||||
|
||||
TRIGGER: Gmail - New Email
|
||||
- From: specific-sender@example.com
|
||||
- Has attachment: yes
|
||||
|
||||
ACTION: Todoist - Create Task
|
||||
- Project: Inbox
|
||||
- Content: {{Email Subject}}
|
||||
- Description: From: {{Email From}}
|
||||
- Due date: Tomorrow
|
||||
"""
|
||||
|
||||
## Make Example
|
||||
"""
|
||||
Scenario: "Gmail to Todoist"
|
||||
|
||||
[Gmail: Watch Emails] → [Todoist: Create a Task]
|
||||
|
||||
Gmail Module:
|
||||
- Folder: INBOX
|
||||
- From: specific-sender@example.com
|
||||
|
||||
Todoist Module:
|
||||
- Project ID: (select from dropdown)
|
||||
- Content: {{1.subject}}
|
||||
- Due String: tomorrow
|
||||
"""
|
||||
|
||||
### Best Practices:
|
||||
- Use descriptive Zap/Scenario names
|
||||
- Test with real sample data
|
||||
- Use filters to prevent unwanted runs
|
||||
|
||||
### Multi-Step Sequential Pattern
|
||||
|
||||
Chain of actions executed in order
|
||||
|
||||
**When to use**: Multi-app workflows, data enrichment pipelines
|
||||
|
||||
# MULTI-STEP SEQUENTIAL:
|
||||
|
||||
"""
|
||||
[Trigger] → [Action 1] → [Action 2] → [Action 3]
|
||||
Each step's output available to subsequent steps
|
||||
"""
|
||||
|
||||
## Zapier Multi-Step Zap
|
||||
"""
|
||||
Zap: "New Lead → CRM → Slack → Email"
|
||||
|
||||
1. TRIGGER: Typeform - New Entry
|
||||
- Form: Lead Capture Form
|
||||
|
||||
2. ACTION: HubSpot - Create Contact
|
||||
- Email: {{Typeform Email}}
|
||||
- First Name: {{Typeform First Name}}
|
||||
- Lead Source: "Website Form"
|
||||
|
||||
3. ACTION: Slack - Send Channel Message
|
||||
- Channel: #sales-leads
|
||||
- Message: "New lead: {{Typeform Name}} from {{Typeform Company}}"
|
||||
|
||||
4. ACTION: Gmail - Send Email
|
||||
- To: {{Typeform Email}}
|
||||
- Subject: "Thanks for reaching out!"
|
||||
- Body: (template with personalization)
|
||||
"""
|
||||
|
||||
## Make Scenario
|
||||
"""
|
||||
[Typeform] → [HubSpot] → [Slack] → [Gmail]
|
||||
|
||||
- Each module passes data to the next
|
||||
- Use {{N.field}} to reference module N's output
|
||||
- Add error handlers between critical steps
|
||||
"""
|
||||
|
||||
### Conditional Branching Pattern
|
||||
|
||||
Different actions based on conditions
|
||||
|
||||
**When to use**: Different handling for different data types
|
||||
|
||||
# CONDITIONAL BRANCHING:
|
||||
|
||||
"""
|
||||
┌→ [Action A] (condition met)
|
||||
[Trigger] ───┤
|
||||
└→ [Action B] (condition not met)
|
||||
"""
|
||||
|
||||
## Zapier Paths (Pro+ required)
|
||||
"""
|
||||
Zap: "Route Support Tickets"
|
||||
|
||||
1. TRIGGER: Zendesk - New Ticket
|
||||
|
||||
2. PATH A: If priority = "urgent"
|
||||
- Slack: Post to #urgent-support
|
||||
- PagerDuty: Create incident
|
||||
|
||||
3. PATH B: If priority = "normal"
|
||||
- Slack: Post to #support
|
||||
- Asana: Create task
|
||||
|
||||
4. PATH C: Otherwise (catch-all)
|
||||
- Slack: Post to #support-overflow
|
||||
"""
|
||||
|
||||
## Make Router
|
||||
"""
|
||||
[Zendesk: Watch Tickets]
|
||||
↓
|
||||
[Router]
|
||||
├── Route 1: priority = urgent
|
||||
│ └→ [Slack] → [PagerDuty]
|
||||
│
|
||||
├── Route 2: priority = normal
|
||||
│ └→ [Slack] → [Asana]
|
||||
│
|
||||
└── Fallback route
|
||||
└→ [Slack: overflow]
|
||||
|
||||
# Make's visual router makes complex branching clear
|
||||
"""
|
||||
|
||||
### Best Practices:
|
||||
- Always have a fallback/else path
|
||||
- Test each path independently
|
||||
- Document which conditions trigger which path
|
||||
|
||||
### Data Transformation Pattern
|
||||
|
||||
Clean, format, and transform data between apps
|
||||
|
||||
**When to use**: Apps expect different data formats
|
||||
|
||||
# DATA TRANSFORMATION:
|
||||
|
||||
## Zapier Formatter
|
||||
"""
|
||||
Common transformations:
|
||||
|
||||
1. Text manipulation:
|
||||
- Split text: "John Doe" → First: "John", Last: "Doe"
|
||||
- Capitalize: "john" → "John"
|
||||
- Replace: Remove special characters
|
||||
|
||||
2. Date formatting:
|
||||
- Convert: "2024-01-15" → "January 15, 2024"
|
||||
- Adjust: Add 7 days to date
|
||||
|
||||
3. Numbers:
|
||||
- Format currency: 1000 → "$1,000.00"
|
||||
- Spreadsheet formula: =SUM(A1:A10)
|
||||
|
||||
4. Lookup tables:
|
||||
- Map status codes: "1" → "Active", "2" → "Pending"
|
||||
"""
|
||||
|
||||
## Make Data Functions
|
||||
"""
|
||||
Make has powerful built-in functions:
|
||||
|
||||
Text:
|
||||
{{lower(1.email)}} # Lowercase
|
||||
{{substring(1.name; 0; 10)}} # First 10 chars
|
||||
{{replace(1.text; "-"; "")}} # Remove dashes
|
||||
|
||||
Arrays:
|
||||
{{first(1.items)}} # First item
|
||||
{{length(1.items)}} # Count items
|
||||
{{map(1.items; "id")}} # Extract field
|
||||
|
||||
Dates:
|
||||
{{formatDate(1.date; "YYYY-MM-DD")}}
|
||||
{{addDays(now; 7)}}
|
||||
|
||||
Math:
|
||||
{{round(1.price * 0.8; 2)}} # 20% discount, 2 decimals
|
||||
"""
|
||||
|
||||
### Best Practices:
|
||||
- Transform early in the workflow
|
||||
- Use filters to skip invalid data
|
||||
- Log transformations for debugging
|
||||
|
||||
### Error Handling Pattern
|
||||
|
||||
Graceful handling of failures
|
||||
|
||||
**When to use**: Any production automation
|
||||
|
||||
# ERROR HANDLING:
|
||||
|
||||
## Zapier Error Handling
|
||||
"""
|
||||
1. Built-in retry (automatic):
|
||||
- Zapier retries failed actions automatically
|
||||
- Exponential backoff for temporary failures
|
||||
|
||||
2. Error handling step:
|
||||
Zap:
|
||||
1. [Trigger]
|
||||
2. [Action that might fail]
|
||||
3. [Error Handler]
|
||||
- If error → [Slack: Alert team]
|
||||
- If error → [Email: Send report]
|
||||
|
||||
3. Path-based handling:
|
||||
[Action] → Path A: Success → [Continue]
|
||||
→ Path B: Error → [Alert + Log]
|
||||
"""
|
||||
|
||||
## Make Error Handlers
|
||||
"""
|
||||
Make has visual error handling:
|
||||
|
||||
[Module] ──┬── Success → [Next Module]
|
||||
│
|
||||
└── Error → [Error Handler]
|
||||
|
||||
Error handler types:
|
||||
1. Break: Stop scenario, send notification
|
||||
2. Rollback: Undo completed operations
|
||||
3. Commit: Save partial results, continue
|
||||
4. Ignore: Skip error, continue with next item
|
||||
|
||||
Example:
|
||||
[API Call] → Error Handler (Ignore)
|
||||
→ [Log to Airtable: "Failed: {{error.message}}"]
|
||||
→ Continue scenario
|
||||
"""
|
||||
|
||||
### Best Practices:
|
||||
- Always add error handlers for external APIs
|
||||
- Log errors to a spreadsheet/database
|
||||
- Set up Slack/email alerts for critical failures
|
||||
- Test failure scenarios, not just success
|
||||
|
||||
### Batch Processing Pattern
|
||||
|
||||
Process multiple items efficiently
|
||||
|
||||
**When to use**: Importing data, bulk operations
|
||||
|
||||
# BATCH PROCESSING:
|
||||
|
||||
## Zapier Looping
|
||||
"""
|
||||
Zap: "Process Order Items"
|
||||
|
||||
1. TRIGGER: Shopify - New Order
|
||||
- Returns: order with line_items array
|
||||
|
||||
2. LOOPING: For each item in line_items
|
||||
- Create inventory adjustment
|
||||
- Update product count
|
||||
- Log to spreadsheet
|
||||
|
||||
Note: Each loop iteration counts as tasks!
|
||||
10 items = 10 tasks consumed
|
||||
"""
|
||||
|
||||
## Make Iterator
|
||||
"""
|
||||
[Webhook: Receive Order]
|
||||
↓
|
||||
[Iterator: line_items]
|
||||
↓ (processes each item)
|
||||
[Inventory: Adjust Stock]
|
||||
↓
|
||||
[Aggregator: Collect Results]
|
||||
↓
|
||||
[Slack: Summary Message]
|
||||
|
||||
Iterator creates one bundle per item.
|
||||
Aggregator combines results back together.
|
||||
Use Array Aggregator for collecting processed items.
|
||||
"""
|
||||
|
||||
### Best Practices:
|
||||
- Use aggregators to combine results
|
||||
- Consider batch limits (some APIs limit to 100)
|
||||
- Watch operation/task counts for cost
|
||||
- Add delays for rate-limited APIs
|
||||
|
||||
### Scheduled Automation Pattern
|
||||
|
||||
Time-based triggers instead of events
|
||||
|
||||
**When to use**: Daily reports, periodic syncs, batch jobs
|
||||
|
||||
# SCHEDULED AUTOMATION:
|
||||
|
||||
## Zapier Schedule Trigger
|
||||
"""
|
||||
Zap: "Daily Sales Report"
|
||||
|
||||
TRIGGER: Schedule by Zapier
|
||||
- Every: Day
|
||||
- Time: 8:00 AM
|
||||
- Timezone: America/New_York
|
||||
|
||||
ACTIONS:
|
||||
1. Google Sheets: Get rows (yesterday's sales)
|
||||
2. Formatter: Calculate totals
|
||||
3. Gmail: Send report to team
|
||||
"""
|
||||
|
||||
## Make Scheduled Scenarios
|
||||
"""
|
||||
Scenario Schedule Options:
|
||||
- Run once (manual)
|
||||
- At regular intervals (every X minutes)
|
||||
- Advanced: Cron expression (0 8 * * *)
|
||||
|
||||
[Scheduled Trigger: Every day at 8 AM]
|
||||
↓
|
||||
[Google Sheets: Search Rows]
|
||||
↓
|
||||
[Iterator: Process each row]
|
||||
↓
|
||||
[Aggregator: Sum totals]
|
||||
↓
|
||||
[Gmail: Send Report]
|
||||
"""
|
||||
|
||||
### Best Practices:
|
||||
- Consider timezone differences
|
||||
- Add buffer time for long-running jobs
|
||||
- Log execution times for monitoring
|
||||
- Don't schedule at exactly midnight (busy period)
|
||||
|
||||
## Sharp Edges
|
||||
|
||||
### Using Text Instead of IDs in Dropdown Fields
|
||||
|
||||
Severity: CRITICAL
|
||||
|
||||
Situation: Configuring actions with dropdown selections
|
||||
|
||||
Symptoms:
|
||||
"Bad Request" errors. "Invalid value" messages. Action fails
|
||||
despite correct-looking input. Works when you select from dropdown,
|
||||
fails with dynamic values.
|
||||
|
||||
Why this breaks:
|
||||
Dropdown menus display human-readable text but send IDs to APIs.
|
||||
When you type "Marketing Team" instead of selecting it, Zapier
|
||||
tries to send that text as the ID, which the API doesn't recognize.
|
||||
|
||||
Recommended fix:
|
||||
|
||||
# ALWAYS use dropdowns to select, don't type
|
||||
|
||||
# If you need dynamic values:
|
||||
|
||||
### Zapier approach:
|
||||
1. Add a "Find" or "Search" action first
|
||||
- HubSpot: Find Contact → returns contact_id
|
||||
- Slack: Find User by Email → returns user_id
|
||||
|
||||
2. Use the returned ID in subsequent actions
|
||||
- Dropdown: Use Custom Value
|
||||
- Select the ID from the search step
|
||||
|
||||
### Make approach:
|
||||
1. Add a Search module first
|
||||
- Search Contacts: filter by email
|
||||
- Returns: contact_id
|
||||
|
||||
2. Map the ID to subsequent modules
|
||||
- Contact ID: {{2.id}} (from search module)
|
||||
|
||||
# Common ID fields that trip people up:
|
||||
- User/Member IDs in Slack, Teams
|
||||
- Contact/Company IDs in CRMs
|
||||
- Project/Folder IDs in project tools
|
||||
- Category/Tag IDs in content systems
|
||||
|
||||
### Zap Auto-Disabled at 95% Error Rate
|
||||
|
||||
Severity: CRITICAL
|
||||
|
||||
Situation: Running a Zap with frequent errors
|
||||
|
||||
Symptoms:
|
||||
Zap suddenly stops running. Email notification about auto-disable.
|
||||
"This Zap was automatically turned off" message. Data stops syncing.
|
||||
|
||||
Why this breaks:
|
||||
Zapier automatically disables Zaps that have 95% or higher error
|
||||
rate over 7 days. This prevents runaway automation failures from
|
||||
consuming your task quota and creating data problems.
|
||||
|
||||
Recommended fix:
|
||||
|
||||
# Prevention:
|
||||
|
||||
1. Add error handling steps:
|
||||
- Use Path: If error → [Log + Alert]
|
||||
- Add fallback actions for failures
|
||||
|
||||
2. Use filters to prevent bad data:
|
||||
- Only continue if email exists
|
||||
- Only continue if amount > 0
|
||||
- Filter out test/invalid entries
|
||||
|
||||
3. Monitor task history regularly:
|
||||
- Check for recurring errors
|
||||
- Fix issues before 95% threshold
|
||||
|
||||
# Recovery:
|
||||
|
||||
1. Check Task History for error patterns
|
||||
2. Fix the root cause (auth, bad data, API changes)
|
||||
3. Test with sample data
|
||||
4. Re-enable the Zap manually
|
||||
5. Monitor closely for next 24 hours
|
||||
|
||||
# Common causes:
|
||||
- Expired authentication tokens
|
||||
- API rate limits
|
||||
- Changed field names in connected apps
|
||||
- Invalid data formats
|
||||
|
||||
### Loops Consuming Unexpected Task Counts
|
||||
|
||||
Severity: HIGH
|
||||
|
||||
Situation: Processing arrays or multiple items
|
||||
|
||||
Symptoms:
|
||||
Task quota depleted unexpectedly. One Zap run shows as 100+ tasks.
|
||||
Monthly limit reached in days. "You've used X of Y tasks" surprise.
|
||||
|
||||
Why this breaks:
|
||||
In Zapier, each iteration of a loop counts as separate tasks.
|
||||
If a webhook delivers an order with 50 line items and you loop
|
||||
through each, that's 50+ tasks for one order.
|
||||
|
||||
Recommended fix:
|
||||
|
||||
# Understand the math:
|
||||
|
||||
Order with 10 items, 5 actions per item:
|
||||
= 1 trigger + (10 items × 5 actions) = 51 tasks
|
||||
|
||||
# Strategies to reduce task usage:
|
||||
|
||||
1. Batch operations when possible:
|
||||
- Use "Create Many Rows" instead of loop + create
|
||||
- Use bulk API endpoints
|
||||
|
||||
2. Aggregate before sending:
|
||||
- Collect all items
|
||||
- Send one summary message, not one per item
|
||||
|
||||
3. Filter before looping:
|
||||
- Only process items that need action
|
||||
- Skip unchanged/duplicate items
|
||||
|
||||
4. Consider Make for high-volume:
|
||||
- Make uses operations, not tasks per action
|
||||
- More cost-effective for loops
|
||||
|
||||
# Make approach:
|
||||
[Iterator] → [Actions] → [Aggregator]
|
||||
- Pay for operations (module executions)
|
||||
- Not per-action like Zapier
|
||||
|
||||
### App Updates Breaking Existing Zaps
|
||||
|
||||
Severity: HIGH
|
||||
|
||||
Situation: App you're connected to releases updates
|
||||
|
||||
Symptoms:
|
||||
Working Zap suddenly fails. "Field not found" errors. Different
|
||||
data format in outputs. Actions that worked yesterday fail today.
|
||||
|
||||
Why this breaks:
|
||||
When connected apps update their APIs, field names can change,
|
||||
new required fields appear, or data formats shift. Zapier/Make
|
||||
integrations may not immediately update to match.
|
||||
|
||||
Recommended fix:
|
||||
|
||||
# When a Zap breaks after app update:
|
||||
|
||||
1. Check the Task History for specific errors
|
||||
2. Open the Zap editor to see field mapping issues
|
||||
3. Re-select the trigger/action to refresh schema
|
||||
4. Re-map any fields that show as "unknown"
|
||||
5. Test with new sample data
|
||||
|
||||
# Prevention:
|
||||
|
||||
1. Subscribe to changelog for critical apps
|
||||
2. Keep connection authorizations fresh
|
||||
3. Test Zaps after major app updates
|
||||
4. Document your field mappings
|
||||
5. Use test/duplicate Zaps for experiments
|
||||
|
||||
# If integration is outdated:
|
||||
- Check Zapier/Make status pages
|
||||
- Report issue to support
|
||||
- Consider webhook alternative temporarily
|
||||
|
||||
# Common offenders:
|
||||
- CRM field restructures
|
||||
- API version upgrades
|
||||
- OAuth scope changes
|
||||
- New required permissions
|
||||
|
||||
### Authentication Tokens Expiring
|
||||
|
||||
Severity: HIGH
|
||||
|
||||
Situation: Using OAuth connections to apps
|
||||
|
||||
Symptoms:
|
||||
"Authentication failed" errors. "Please reconnect" messages.
|
||||
Zaps fail after weeks of working. Multiple apps fail simultaneously.
|
||||
|
||||
Why this breaks:
|
||||
OAuth tokens expire. Some apps require re-authentication every
|
||||
60-90 days. If the user who connected the app leaves the company,
|
||||
their connection may stop working.
|
||||
|
||||
Recommended fix:
|
||||
|
||||
# Immediate fix:
|
||||
1. Go to Settings → Apps
|
||||
2. Find the app with issues
|
||||
3. Reconnect (re-authorize)
|
||||
4. Test affected Zaps
|
||||
|
||||
# Prevention:
|
||||
|
||||
1. Use service accounts for connections
|
||||
- Don't connect with personal accounts
|
||||
- Use shared team email/account
|
||||
|
||||
2. Monitor connection health
|
||||
- Check Apps page regularly
|
||||
- Set calendar reminders for known expiration
|
||||
|
||||
3. Document who connected what
|
||||
- Track in spreadsheet
|
||||
- Handoff process when people leave
|
||||
|
||||
4. Prefer connections that don't expire
|
||||
- API keys over OAuth when available
|
||||
- Long-lived tokens
|
||||
|
||||
# Zapier Enterprise:
|
||||
- Admin controls for managing connections
|
||||
- SSO integration
|
||||
- Centralized connection management
|
||||
|
||||
### Webhooks Missing or Duplicating Events
|
||||
|
||||
Severity: MEDIUM
|
||||
|
||||
Situation: Using webhooks as triggers
|
||||
|
||||
Symptoms:
|
||||
Some events never trigger the Zap. Same event triggers multiple
|
||||
times. Inconsistent automation behavior. "Works sometimes."
|
||||
|
||||
Why this breaks:
|
||||
Webhooks are fire-and-forget. If Zapier's receiving endpoint is
|
||||
slow or unavailable, the webhook may fail. Some systems retry
|
||||
webhooks, causing duplicates. Network issues lose events.
|
||||
|
||||
Recommended fix:
|
||||
|
||||
# Handle duplicates:
|
||||
|
||||
1. Add deduplication logic:
|
||||
- Filter: Only continue if ID not in Airtable
|
||||
- First action: Check if already processed
|
||||
|
||||
2. Use idempotency:
|
||||
- Store processed IDs
|
||||
- Skip if ID exists
|
||||
|
||||
### Zapier example:
|
||||
[Webhook Trigger]
|
||||
↓
|
||||
[Airtable: Find Records] - search by event_id
|
||||
↓
|
||||
[Filter: Only continue if not found]
|
||||
↓
|
||||
[Process Event]
|
||||
↓
|
||||
[Airtable: Create Record] - store event_id
|
||||
|
||||
# Handle missed events:
|
||||
|
||||
1. Use polling triggers for critical data
|
||||
- Less real-time but more reliable
|
||||
- Catches events during downtime
|
||||
|
||||
2. Implement reconciliation:
|
||||
- Scheduled Zap to check for gaps
|
||||
- Compare source data to processed data
|
||||
|
||||
3. Check source system retry settings:
|
||||
- Some systems retry on failure
|
||||
- Configure retry count/timing
|
||||
|
||||
### Make Operations Consumed by Error Retries
|
||||
|
||||
Severity: MEDIUM
|
||||
|
||||
Situation: Scenarios with failing modules
|
||||
|
||||
Symptoms:
|
||||
Operations quota depleted quickly. Scenario runs "succeeded" but
|
||||
used many operations. Same scenario running more than expected.
|
||||
|
||||
Why this breaks:
|
||||
Make counts operations per module execution, including failed
|
||||
attempts and retries. Error handler modules consume operations.
|
||||
Scenarios that fail and retry can use 3-5x expected operations.
|
||||
|
||||
Recommended fix:
|
||||
|
||||
# Understand operation counting:
|
||||
|
||||
Successful run: Each module = 1 operation
|
||||
Failed + retry (3x): 3 operations for that module
|
||||
Error handler: Additional operation per handler module
|
||||
|
||||
# Reduce operation waste:
|
||||
|
||||
1. Add error handlers that break early:
|
||||
[Module] → Error → [Break] (1 additional op)
|
||||
vs
|
||||
[Module] → Error → [Log] → [Alert] → [Update] (3+ ops)
|
||||
|
||||
2. Use ignore instead of retry when appropriate:
|
||||
- If failure is expected (record exists)
|
||||
- If retrying won't help (bad data)
|
||||
|
||||
3. Pre-validate before expensive operations:
|
||||
[Check Data] → Filter → [API Call]
|
||||
- Fail fast before consuming operations
|
||||
|
||||
4. Optimize scenario scheduling:
|
||||
- Don't run every minute if hourly is enough
|
||||
- Use webhooks for real-time when possible
|
||||
|
||||
# Monitor usage:
|
||||
- Check Operations dashboard
|
||||
- Set up usage alerts
|
||||
- Review high-consumption scenarios
|
||||
|
||||
### Timezone Mismatches in Scheduled Triggers
|
||||
|
||||
Severity: MEDIUM
|
||||
|
||||
Situation: Setting up scheduled automations
|
||||
|
||||
Symptoms:
|
||||
Zap runs at wrong time. "9 AM" trigger fires at 2 PM. Different
|
||||
behavior on different days. DST causes hour shifts.
|
||||
|
||||
Why this breaks:
|
||||
Zapier shows times in your local timezone but may store in UTC.
|
||||
If you change timezones or DST occurs, scheduled times shift.
|
||||
Team members in different zones see different times.
|
||||
|
||||
Recommended fix:
|
||||
|
||||
# Best practices:
|
||||
|
||||
1. Explicitly set timezone in schedule:
|
||||
- Don't rely on browser detection
|
||||
- Use business timezone, not personal
|
||||
|
||||
2. Document in Zap name:
|
||||
- "Daily Report 9AM EST"
|
||||
- Include timezone in description
|
||||
|
||||
3. Test around DST transitions:
|
||||
- Schedule changes at DST boundaries
|
||||
- Verify times before/after change
|
||||
|
||||
4. For global teams:
|
||||
- Use UTC as standard
|
||||
- Convert to local in descriptions
|
||||
|
||||
5. Consider buffer times:
|
||||
- Don't schedule at exactly midnight
|
||||
- Avoid on-the-hour (busy periods)
|
||||
|
||||
### Make timezone handling:
|
||||
- Scenarios use account timezone setting
|
||||
- formatDate() function respects timezone
|
||||
- Use parseDate() with explicit timezone
|
||||
|
||||
## Collaboration
|
||||
|
||||
### Delegation Triggers
|
||||
|
||||
- automation requires custom code -> workflow-automation (Code-based solutions like Inngest, Temporal)
|
||||
- need browser automation in workflow -> browser-automation (Playwright/Puppeteer integration)
|
||||
- building custom API integration -> api-designer (API design and implementation)
|
||||
- automation needs AI capabilities -> agent-tool-builder (AI agent tools and Zapier MCP)
|
||||
- high-volume data processing -> backend (Custom backend processing)
|
||||
- need self-hosted automation -> devops (n8n or custom workflow deployment)
|
||||
|
||||
## Related Skills
|
||||
|
||||
Works well with: `workflow-automation`, `agent-tool-builder`, `backend`, `api-designer`
|
||||
|
||||
## When to Use
|
||||
- User mentions or implies: zapier
|
||||
- User mentions or implies: make
|
||||
- User mentions or implies: integromat
|
||||
- User mentions or implies: zap
|
||||
- User mentions or implies: scenario
|
||||
- User mentions or implies: no-code automation
|
||||
- User mentions or implies: trigger action
|
||||
- User mentions or implies: workflow automation
|
||||
- User mentions or implies: connect apps
|
||||
- User mentions or implies: automate
|
||||
|
||||
## Limitations
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
||||
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|
||||
Reference in New Issue
Block a user