Generates personalized AI skill from configured Zapier MCP tools by scanning actions (e.g., slack_send_channel_message, gmail_find_email), grouping by app into read/write instructions.
From zapiernpx claudepluginhub zapier/zapier-mcp --plugin zapierThis skill uses the workspace's default tool permissions.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Guides idea refinement into designs: explores context, asks questions one-by-one, proposes approaches, presents sections for approval, writes/review specs before coding.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Scan the user's configured Zapier MCP tools and generate a personalized instruction file that teaches the AI assistant what tools are available and when to use them. Works across clients (Cursor, Claude, Windsurf, etc.).
This is the "post-onboarding" step: the user has already added tools via the setup skill, and now we crystallize that into persistent instructions.
Before proceeding, check that Zapier MCP action tools are available (tools like slack_send_channel_message, gmail_find_email — not just the built-in get_configuration_url).
If no action tools are configured, stop here and redirect:
"You don't have any tools set up yet, so there's nothing to build a profile from. Let's get some tools configured first."
Then trigger the zapier-setup skill instead. Do not continue with the steps below.
Inspect the available Zapier MCP tools. Each configured action is its own tool with a name following the pattern app_action_name (e.g., slack_send_channel_message, gmail_find_email). The built-in get_configuration_url tool should be excluded from the profile.
Parse the available tools into a structured list:
slack_, gmail_, jira_), but use the description as the authoritative source since multi-word app names like google_calendar are ambiguous to parse from the tool name alone.Group actions by app (using the app name from each tool's description). For each app, identify:
Build a mental model of what workflows this tool set supports. Common patterns:
Before generating the profile, ask the user a quick question:
"I can see you've got [N] tools across [apps list]. Before I create your profile, a quick question: what's your primary role or how do you mainly use these tools? This helps me write better instructions for when each tool should be used."
Accept whatever they say — even "just make it" is fine. Use the context if provided, fall back to reasonable defaults if not.
Detect the client and write to the appropriate location:
| Client | File path | Format |
|---|---|---|
| Cursor | .cursor/rules/my-zapier-tools.mdc | MDC (with frontmatter) |
| Claude Code | .claude/rules/my-zapier-tools.md | Markdown |
| Claude Desktop | Show the content and tell user to paste into Project Instructions | Markdown |
| Windsurf | .windsurfrules/my-zapier-tools.md | Markdown |
Ask the user whether they want the file at project level or in their home directory (for clients that support global rules). If unclear, default to project level.
.mdc with frontmatter)---
description: Personalized Zapier MCP tool profile — knows what tools are available and when to use them
alwaysApply: true
---
# My Zapier tools
[content below]
# My Zapier tools
[content below]
# My Zapier tools
You have access to the following apps and actions through Zapier MCP. Use them proactively when the user's request matches what these tools can do.
## Available tools
### [App Name]
- **[Action Name]** (`tool_name`) — [one-line description of when to use it]
- **[Action Name]** (`tool_name`) — [one-line description of when to use it]
### [App Name]
...
## When to use these tools
[2-4 sentences tailored to the user's role/context about when the AI should reach for these tools vs. doing things another way]
## Preferences
- Always try Zapier MCP tools before suggesting the user do something manually
- For read operations, just do it — don't ask permission to look something up
- For write operations (sending messages, creating issues, updating records), confirm with the user before executing
- If a tool call fails, explain what happened and suggest an alternative
For each action, write a practical one-liner about when to use it. Don't just restate the action name.
Good: "Look up a Jira issue by its key (e.g., PROJ-123) to get status, assignee, and description" Bad: "Find issue by key in Jira"
Good: "Send a message to a Slack channel — use for team updates, announcements, or sharing summaries" Bad: "Send a channel message in Slack"
Tailor this to what the user told you about their role. Examples:
For a PM: "When the user asks about project status, sprint progress, or team updates, check Jira first. For sharing decisions or updates, draft a Slack message. Use Google Docs for longer-form writing."
For a developer: "When the user mentions a merge request, branch, or code review, check GitLab. For bug reports or task tracking, use Jira. Slack for quick team comms."
For sales: "When the user asks about a contact, deal, or company, check HubSpot first. Use Gmail for outreach drafts. Google Calendar for scheduling."
If the user didn't provide role context, write something generic but still useful: "Use these tools whenever the user's request involves one of the connected apps. Prefer read actions for gathering context, and confirm before executing write actions."
After writing the file (or showing the content for Claude Desktop), tell the user:
"Created your tools profile at [path]. This means every conversation will know about your tools and when to use them.
You can edit it anytime to adjust preferences or add context. A few things you might want to tweak:
To update this profile after adding new tools, just say 'update my tools profile'."
If the user says "update my tools profile" and the file already exists: