AI agent skills are reusable procedures that a compatible agent can discover and apply to recurring work. A support-triage skill, for example, can tell an agent how to read a ticket, search permitted reference sources, classify the issue, and prepare an evidence-linked recommendation for a representative.
A skill describes the procedure. It does not automatically provide the data, application access, permissions, deterministic checks, or accountable owner required to run that procedure safely. The strongest implementations combine a skill with connected tools, explicit automation, validation, and human review.
Use a skill when a task repeats, has recognizable inputs and outputs, and benefits from reusable context. Use a prompt for a one-off request, a connected tool for access to information or actions, and deterministic automation for explicit rules such as an SLA threshold.
What is an AI agent skill?
In Anthropic’s documented approach, an Agent Skill is a directory containing a required SKILL.md file and optional scripts, reference files, and other assets. The Markdown file uses YAML frontmatter, including a name and description, followed by instructions for the task. Anthropic announced Agent Skills in October 2025 and said in December 2025 that it had published the format as an open standard. Its Agent Skills announcement explains the format and its progressive-disclosure model.
Progressive disclosure means that metadata can help identify whether a skill is relevant, the instruction body can be loaded when needed, and supporting resources can be consulted for the specific task. Anthropic’s skill-authoring guidance recommends defining triggers, expected outputs, dependencies, edge cases, and test prompts before finalizing a skill.
Think of a skill as a reusable procedure with supporting context, not as a standalone agent, application connection, or guarantee of correct execution. The same folder may be reusable across compatible hosts, but discovery rules, available tools, paths, authentication, scripts, and triggering behavior can differ.
When should a team use a skill instead of a prompt, tool, or automation?
Assign each part of the workflow to the mechanism suited to it. Always-on instructions set broad defaults such as identity, tone, or preferred formatting. A skill describes how to handle a particular recurring job. A tool or MCP connection exposes selected information or actions. Deterministic automation applies explicit conditions, routing rules, and validations.
| Mechanism | Best fit | Example |
|---|---|---|
| Always-on instruction | Defaults across many tasks | Use the approved tone in drafts. |
| Skill | Repeatable process requiring context | Interpret a ticket and recommend a next step. |
| Tool or MCP | Selected data or actions | Search an authorized helpdesk or knowledge base. |
| Deterministic automation | Explicit, testable rules | Flag a lead after a defined business-hours SLA. |
A useful decision test is: does the task repeat, have bounded inputs and outputs, benefit from reusable context, and have a person or system owner for exceptions? If the criteria are fully deterministic, do not use a model where a rule will be more reliable. If the work requires interpreting unstructured material from several sources, a skill can provide the operating procedure around that interpretation.
For a lead audit, deterministic logic can select leads that meet a stated SLA condition. A skill can interpret conversation history to distinguish a delay from a recorded deferment. Deterministic validation can then check required fields and allowed values before any finding is created.
Zapier MCP can connect compatible AI clients to selected supported applications and actions, subject to authorization, configuration, product limits, and the exact app capability. MCP supplies access, not proof that the agent selected the right record, followed the business rule, or obtained approval. Zapier also uses the term “Skills” for reusable workflows in its own product context, which should not automatically be treated as the open SKILL.md convention.
A skill can guide how an agent handles a job. Data access, deterministic checks, permissions, and ownership still belong to the surrounding operational system.
How to inspect, install, and create a skill
Installation is a host-specific deployment task, not simply copying SKILL.md and assuming it will work. Use the host’s documented method and confirm its discovery rules. The Wade Skills repository, for example, documents several product-specific installation approaches and contains setup placeholders. It is a starting point that users must configure, not a turnkey integration.
Before installing a public skill, inspect its instructions, scripts, external URLs, setup notes, dependencies, and requested access. Treat those files and dependencies as part of the agent’s trust boundary. Confirm whether scripts execute locally, in a sandbox, or through an external service. Pin a reviewed version or commit where practical, use a restricted account, and test with nonproduction data.
For a new skill, define the trigger, task boundary, inputs, expected output, dependencies, edge cases, and test prompts before drafting the instructions.
Three operational patterns for AI agent skills
The following designs translate publicly described workflow patterns into proposed implementation contracts. Their fields, validation gates, record grains, and writeback controls are editorial recommendations, not published vendor schemas. Zapier’s ClickUp customer story describes support research and triage at a high level. Zapier’s GTM skill breakdown describes campaign postmortem and lead-treatment audit patterns. It is not a verified production template or field mapping.
| Trigger and inputs | AI job and output | Validation and action | Fallback |
|---|---|---|---|
| Support triage Ticket ID, URL, or text. Retrieve permitted ticket, knowledge-base, and issue-tracker records. |
Classify the issue and recommend a next action. Return ticket_id, run_id, category, severity, source_record_ids, recommendation, and review status. | Verify the ticket and cited records. Save an internal summary. Require approval before a customer reply or ticket change. | Missing or conflicting evidence produces an insufficient-evidence state for the representative or escalation queue. |
| Campaign review Campaign ID, reporting period, agreed attribution definition, performance reports, feedback, and source notes. |
Separate observed facts, interpretations, missing data, and recommendations. Link material findings to source IDs. | Check that metrics share the same period and attribution definition. Save a reviewed retrospective before budget, targeting, or messaging changes. | The campaign owner resolves conflicting metrics. The skill must not silently choose a dashboard value. |
| Lead audit Lead ID, owner, timestamps, assignment history, activity records, and response-time policy. |
Interpret activity context to identify a likely gap, deferment, or routing issue, with evidence activity IDs. | Apply the stated business-hours clock and timezone. Create only an owner-reviewed finding, not an inferred ownership change. | Sales operations investigates missing system activity or duplicate records before creating a task. |
For support triage, retrieve the ticket and permitted reference records, classify the issue, verify that cited records exist, and save an internal summary. A missing article or conflicting issue record should produce review, not a guessed resolution.
For a campaign retrospective, retrieve the agreed reports and feedback, check the reporting window and attribution definition, and distinguish measured results from interpretation. Preserve disagreements for the campaign owner.
For a lead audit, apply the organization’s explicit business-hours clock, retrieve ownership and activity history, and explain a suspected gap with supporting activity IDs. An empty CRM activity history is not proof that no follow-up occurred elsewhere.
Design the output contract, evidence trail, and duplicate controls
A structured result makes a recommendation easier to validate and route. The following is an illustrative contract for one triage observation from one processing run. It is not a ClickUp field list.
{
"ticket_id": "TICKET-1042",
"run_id": "triage-2026-11-14-001",
"issue_category": "illustrative-category",
"severity": "review",
"recommended_next_action": "Check the linked issue with the product team",
"source_record_ids": [
"helpdesk-record-71",
"issue-record-23"
],
"confidence": 0.78,
"human_review_required": true,
"processed_at": "2026-11-14T16:25:00Z",
"skill_version": "reviewed-version-1"
}Keep source facts separate from the agent’s interpretation. Every recommendation should point to retrieved records. If evidence is missing, unavailable, or contradictory, return a review state. Retain the run ID, source IDs, processing time, skill version, and approval status.
Define the row grain before saving results. For triage, one row can represent one observation for one ticket-processing run. A suitable proposed key is ticket_id + run_id, or ticket_id + source_version when the workflow intentionally processes a particular version. Do not use ticket_id alone if a ticket can change and be reprocessed.
For campaign postmortems, use one parent record per campaign, reporting period, attribution definition, and version. Store source citations as separate child records. For lead audits, use one finding per lead-handling event or SLA breach, keyed with the relevant activity and rule version. Do not collapse multiple events into one lead-per-day row.
A search followed by a create can produce duplicates when two workers process the same event concurrently. Use a database-enforced unique constraint or transactional upsert where supported. If the destination cannot provide one, use a durable idempotency record or serialized queue. These are implementation recommendations, not documented features of the linked vendor examples.
When writing to a CRM, keep the CRM or designated application as the system of record. Before an approved write, verify record identity, permitted fields, valid values, required fields, record freshness, and whether the proposed task or note already exists. Store the evidence and run identifier. A skill can draft or propose an update, while a validated application workflow or authorized person performs it under the agreed approval rules. CRM systems consulting can help teams define those writeback controls.
Test performance and set approval boundaries
Test normal cases, missing sources, ambiguous records, stale data, and high-impact exceptions. Score outputs against an agreed rubric, including evidence quality, required fields, correct review routing, and prohibited actions. Measure the operational outcome that matters, such as research minutes per ticket, recommendations with usable evidence, or audit findings confirmed by owners. Set a baseline and measurement period before claiming improvement.
Zapier reports that ClickUp reduced research time from about 15 minutes to about 4 minutes per ticket and estimated 917+ hours saved monthly across approximately 5,000 tickets. These are vendor-reported customer-story figures, not an independently audited benchmark or a guarantee for another implementation. The story does not disclose the complete internal prompt, schema, confidence threshold, retry logic, deduplication design, or permission model.
Match approval to the action. An internal summary may need less oversight than an external message. Require explicit review for customer replies, ownership changes, deletion, financial actions, and other high-impact or difficult-to-reverse updates. Before connecting an agent, confirm permitted data sources, PII and contractual restrictions, account scopes, and who can authorize changes.
- Normal, ambiguous, stale, and missing-source tests pass the agreed rubric.
- Source IDs, run details, and approval status are retained with each recommendation.
- Application access is limited to the data and actions the workflow needs.
- Writeback fields, freshness checks, validation, and concurrency-safe deduplication are tested.
- A named person or queue owns exceptions and approval decisions.
A practical go or no-go test
Proceed when the task repeats, its inputs and output are bounded, the host and required connections are confirmed, and a named owner can handle exceptions. Start with read-and-recommend behavior. Add write actions only after evidence, validation, permissions, duplicate handling, and approval rules have been tested.
Use a prompt for a one-off task, explicit automation for fully deterministic criteria, or process clarification when data and approvals are unclear. For teams ready to operationalize a tested workflow, AI agent implementation can help define system boundaries and release controls.