Build custom skills for proprietary workflows and organization-specific context if your team can maintain them. Use trusted, licensed public skills for common tasks. Either way, Atlan’s Context Layer for AI is what validates the skill actually works against your real business context before it runs in production.
The right choice depends on five signals:
-
Workflow specificity: Standard process or proprietary internal workflow
-
Source and security: Verified origin, audited files, and appropriate permissions
-
Maintenance ownership: Named owner for testing, updates, and broken dependencies
-
Context requirements: Public information or governed internal business context
-
License fit: Terms covering intended use, modification, attribution, and redistribution
Below, we break down what each path requires, where it can fail, and how to choose between them.
What does a public agent skill actually give you?
Permalink to “What does a public agent skill actually give you?”A public agent skill gives you a reusable set of instructions for a task that another developer or organization has already defined and shared. It can shorten discovery and authoring time for common work such as document creation, code review, creating slide decks, designing one-page internal websites, etc.
The open Agent Skills specification standardizes a folder with a required SKILL.md file and optional scripts, references, and assets. That common shape makes public skills easier to inspect, move, and adapt across compatible products. It also separates what an agent skill actually is from the directory that distributes it.
Teams typically find public skills through two types of registries:
-
Curated directories: Anthropic’s Skills Directory includes Anthropic-created skills and professionally built partner skills. This provides clearer provenance, but teams still need to confirm workflow fit, permissions, and behavior before deployment.
-
Community registries: ClawHub and skills.sh make independently published skills easier to discover. Review practices and maintenance quality can vary, so teams need to inspect the complete bundle, source repository, dependencies, and requested access.
A registry can help establish where a skill came from, but it cannot prove that the skill is complete, reliable, or suitable for a particular workflow. SKILL.md’s frontmatter and progressive disclosure model helps an agent identify and load relevant instructions, while the author still controls the instructions, scripts, references, and dependencies inside the skill. Simon Willison called the Agent Skills specification “deliciously tiny” and “quite heavily under-specified”, reinforcing why teams must inspect each skill before use.
Atlan’s view is that a public skill provides a reusable procedure, not the approved business context or system access needed to execute it reliably. This is why agent skills with MCP and agent skills with tools are related but separate: the skill explains how to work, while tools and access paths connect the agent to live systems. Managing that combination is part of skill engineering, which goes beyond prompt engineering; if the procedure itself depends on proprietary rules, private systems, or organization-specific exceptions, a public skill may no longer fit.
When does a workflow require a custom agent skill?
Permalink to “When does a workflow require a custom agent skill?”Public skills work best for standardized tasks such as document processing, Git operations, and common API workflows. They can often accommodate minor changes to inputs, examples, settings, or output formats. A custom skill becomes justified when proprietary rules, systems, or exceptions require rewriting the core logic.
A custom skill is usually justified in four scenarios:
-
Proprietary workflows: Internal approval chains, escalation paths, exception policies, and decision rules that encode how the organization operates.
-
Internal tools and APIs: Private services, endpoints, SDKs, or data models that an external skill author cannot access or test.
-
Organization-specific policy: Compliance rules, data restrictions, business definitions, and regional requirements that must match approved internal sources.
-
Composite internal workflows: Tasks that coordinate several private systems in a sequence specific to the organization.
If these requirements change the workflow’s core steps, tools, or exception handling, writing a SKILL.md from scratch is often cleaner than repeatedly modifying a generic public skill. Custom authorship still requires agent skill best practices and an enterprise skills governance model for testing, approval, versioning, and ownership.
A custom skill does not always begin with a blank page. A public skill can provide a structural reference, while an enterprise context layer supplies approved definitions, policies, and operational context. Once the organization owns the core logic and maintenance, however, the resulting skill should be governed as a custom asset.
Regardless of where the starting point comes from, the skill still requires a security review.
What is the real risk with public skills?
Permalink to “What is the real risk with public skills?”The main public-skill risk is not that every community skill is malicious. It is that a skill can contain instructions, scripts, downloads, and references that influence an agent with the permissions already available to that runtime.
According to Snyk’s ToxicSkills research (2026), 1,467 of 3,984 skills scanned from ClawHub and skills.sh, or 36.82%, had at least one security issue.
Snyk’s findings show why public-skill review belongs within broader AI security for enterprise agents. Before deployment, teams need to check for prompt injection attacks, unexpected network access, excessive permissions, and data privacy risks.
Anthropic’s own security guidance says to use trusted sources and thoroughly audit skills from unknown sources. The review has to cover every bundled file, unexpected network or file access, external dependencies, requested tools, and whether the behavior matches the stated purpose.
Building a custom agent skill does not remove these risks. An internal skill can still request excessive permissions, contain incorrect business logic, or fail when its APIs and dependencies change. The difference is that public skills introduce third-party uncertainty, while custom skills place responsibility for those failures on internal owners.
What does it cost to maintain a custom agent skill?
Permalink to “What does it cost to maintain a custom agent skill?”Building a custom skill creates recurring work after the first version ships. A skill is not static: it embeds assumptions about API endpoints, package versions, authentication methods, configuration defaults, and data schemas. When its environment changes, those assumptions can fail even if the skill itself has not changed.
A 2026 preprint on skill drift describes these assumptions as contracts between a skill and its operating environment. In its experiments, identifying the violated contract improved one-round repair success from 10% to 78%.
This result does not tell teams exactly how much maintenance will cost. It shows that documenting a skill’s dependencies makes problems easier to find and fix.
The recurring burden of managing a custom agent skill falls into four categories:
-
Business review: Keeping procedures, policies, approval rules, and exceptions current
-
Technical maintenance: Updating tools, dependencies, permissions, and integrations
-
Regression testing: Confirming that expected tasks and edge cases still work after changes
-
Release control: Recording versions, approving updates, monitoring releases, and maintaining rollback paths
One person may cover more than one, but every category needs a named owner. Otherwise, dependency changes or outdated policies can remain unnoticed until the skill produces an incorrect result.
Skills and their context can also drift independently. Versioned context for AI agents matters because a skill can remain unchanged while the business definition or policy it uses becomes outdated. Detecting that context drift is part of the maintenance cost.
Custom skills create an internal maintenance obligation. Reusing public skills introduces another ongoing responsibility: tracking their source and license terms.
What licensing and attribution obligations come with public skills?
Permalink to “What licensing and attribution obligations come with public skills?”The Agent Skills specification includes an optional license field that can name a license or reference a bundled license file. A publicly accessible skill is not necessarily free from restrictions, and a missing license field does not prove that reuse is permitted.
Before adopting, modifying, or redistributing a public skill, verify these terms:
-
Governing license: The license named in SKILL.md, the repository, or a bundled license file
-
Permitted use: Terms covering internal use, modification, commercial use, and redistribution
-
Notices and attribution: Required copyright notices, license copies, credits, or NOTICE files
-
Copyleft obligations: Source-disclosure or same-license requirements that may apply when modified versions are created
-
Change history: The original source and revision, modifications made, and version being deployed
Internal use may trigger fewer distribution obligations under some licenses, but teams should not assume that it is obligation-free. Sharing a modified skill with customers, partners, or product users can create additional notice, attribution, source-disclosure, or licensing requirements. If the terms are unclear, the owner or legal team should resolve them before deployment.
Record this information with the skill’s provenance in an AI registry or equivalent internal inventory. Teams should be able to identify where the skill came from, which version they use, what they changed, and which license obligations apply.
How should teams choose between a public and custom agent skill?
Permalink to “How should teams choose between a public and custom agent skill?”Choose the path that meets the workflow’s requirements with a level of risk, cost, and maintenance the team can accept.
MIT CISR’s buy, boost, or build framework supports the same principle: understand the organization’s strengths and limitations before deciding whether to acquire or develop an AI capability.
Before writing or installing a skill, ask five questions:
-
Is the workflow standardized or proprietary? Use a public skill when the process is common across organizations. Build custom when internal rules, systems, or exceptions determine the core steps.
-
Can the team audit the complete skill? Review SKILL.md, scripts, references, dependencies, permissions, and network access. Do not deploy a skill that the team cannot inspect and test, regardless of who wrote it.
-
Who will maintain it? A public skill requires monitoring its source and reviewing upstream changes before installation. A custom skill requires an internal owner for testing, updates, fixes, and rollback.
-
Does the workflow depend on live business context? A public skill can still work when its procedure remains generic and approved context is supplied separately. Build custom when internal definitions or policies change the workflow’s core decision logic.
-
Does the license fit the intended use? Confirm that the terms cover modification, commercial use, redistribution, attribution, and any required notices.
Keep this choice separate from runtime architecture. An agent harness controls execution, while MCP and tool use determine how the agent reaches systems. Either architecture can support a public or custom skill.
How does Atlan provide reliable context for public and custom agent skills?
Permalink to “How does Atlan provide reliable context for public and custom agent skills?”Choosing where a skill comes from is only the first decision. Public and custom skills both need approved business context, controlled access, testing, versioning, and review before an agent uses them in production.
Atlan, the Context Layer for AI, applies the same governed-context discipline to both paths.
These requirements map to Atlan’s capabilities as follows:
| What teams need | Atlan capability | How it supports both paths |
|---|---|---|
| Maintain the business context behind the skill | Context Agents | Use table structure, query history, lineage, and business glossary context to enrich the context agents depend on |
| Build, test, and approve context | Context Engineering Studio | Bootstrap a Context Repo, run evaluations, identify gaps, and let domain experts review changes before deployment |
| Version changes and support rollback | Context Repos | Keep skills, knowledge, tools, tests, and approval history in bounded, versioned units |
| Deliver approved context at runtime | Context Lakehouse | Serve governed context through MCP, A2A, SQL, and APIs instead of storing a static snapshot in the skill |
Together, these capabilities provide governed context for agent skills across either path. A public or custom skill can define how work should run, while Atlan supplies current definitions, policies, lineage, and quality signals. This is why AI agents need an enterprise context layer: a reviewed skill can still fail when the context it uses is outdated.
These controls do not replace security review, licensing checks, or named ownership of the skill itself. They ensure that whichever skill is deployed uses approved context and follows a testable, versioned path to production.
What can go wrong with a custom agent skill?
Permalink to “What can go wrong with a custom agent skill?”A mid-market data and analytics SaaS company had built several ad hoc custom skills by describing tasks directly to its AI assistant, alongside extensive MCP use for talk-to-data workflows. When reviewed, the skills turned out to be a single unscoped file with no specialization.
Building internally provides control, but not automatic reliability. A custom skill still needs a clear scope, specialized instructions, testing, and a named owner before it enters production.
What should teams do next?
Permalink to “What should teams do next?”Use a trusted public skill when the workflow is standardized, and the source and license meet your requirements. Build a custom agent skill when proprietary systems, policies, or exceptions determine how the work must be done. The right choice is the one your team can securely deploy and maintain over time.
Whichever path you choose, inspect the complete skill, test its behavior, limit its permissions, and assign an owner for updates and releases. Public skills require continued review of third-party changes, while custom skills require continued maintenance of internal logic and dependencies.
Finally, keep the procedure separate from the business context it uses. A well-built skill still needs current, approved definitions, policies, and quality signals to produce reliable results in production.
Context Gap Calculator
See how much of the business context behind your agent skills is actually reliable today, before you decide whether to build or adopt the next one.
Calculate Your Context GapFAQ
Permalink to “FAQ”1. Should I write my own Claude Skill or use one from a marketplace like ClawHub or skills.sh?
Permalink to “1. Should I write my own Claude Skill or use one from a marketplace like ClawHub or skills.sh?”Use a public skill when the workflow is common, the source is trusted, and the license fits your intended use. Write your own when the core procedure depends on proprietary tools, policies, or decision logic. A public fork can reduce authoring work, but once its core logic is modified, treat it as an internally owned custom skill. Neither path is automatically safe, so inspect and test the complete skill before production.
2. Are public AI agent skills safe to install without review?
Permalink to “2. Are public AI agent skills safe to install without review?”No. A public skill can include instructions, scripts, downloads, and references that influence an agent’s tool use. In Snyk’s February 2026 sample of 3,984 skills from ClawHub and skills.sh, 36.82% had at least one security issue and 13.4% had at least one critical issue. Those findings do not describe every public skill, but they show why teams should review the complete bundle and test it in isolation before granting access to sensitive systems.
3. What is the difference between Anthropic’s official Skills directory and open community registries?
Permalink to “3. What is the difference between Anthropic’s official Skills directory and open community registries?”Anthropic’s directory includes Anthropic-created and partner skills designed for Claude, which gives teams clearer provenance. Open community registries index skills from a broader range of independent publishers, so review and maintenance practices can vary. A listing in either type does not prove that a skill is secure or suitable for an internal workflow.
4. How much ongoing maintenance does a custom SKILL.md require?
Permalink to “4. How much ongoing maintenance does a custom SKILL.md require?”Maintenance depends on how many external contracts the skill relies on. APIs, commands, packages, schemas, policies, and examples all create change surfaces. A stable text-only formatting skill may need little work, while a production skill using private systems needs tests, an owner, update review, and rollback. Budget for maintenance as long as the workflow remains active.
5. Can you fork or customize a public skill instead of writing one from scratch?
Permalink to “5. Can you fork or customize a public skill instead of writing one from scratch?”Yes, and that is often the most practical middle path. Fork when the public procedure is sound but your tools, examples, or policy differ. Preserve the source, license, and change history, then test the fork as an internally owned artifact. Upstream updates should be reviewed before merging into the fork.
6. Do public agent skills come with licensing or attribution obligations?
Permalink to “6. Do public agent skills come with licensing or attribution obligations?”They can. The license may require attribution, notices, source disclosure, or specific redistribution terms. An absent license field in SKILL.md does not prove unrestricted reuse because the repository may define terms elsewhere. Record the applicable license and revision before modifying or distributing the skill.
7. What security risks come with installing a third-party agent skill?
Permalink to “7. What security risks come with installing a third-party agent skill?”Risks include hidden instructions, prompt injection, malicious scripts, credential exposure, unsafe downloads, and excessive tool permissions. External files or packages can also change after the first review. Limit permissions, pin dependencies where possible, scan the bundle, and monitor the installed version. Treat installation like adding software to an agent runtime.
8. When does an internal or proprietary workflow require a custom skill instead of an off-the-shelf one?
Permalink to “8. When does an internal or proprietary workflow require a custom skill instead of an off-the-shelf one?”Build custom when the workflow’s core value comes from internal decision logic, private APIs, approval chains, regulated handling, or organization-specific exceptions. A custom skill is also justified when the procedure must coordinate several internal systems in a sequence unique to the organization. Small output or terminology changes usually do not justify a full rewrite. If using a public skill would require replacing its core procedure, a clean custom skill is easier to own.
9. How do you evaluate a public skill before adopting it into a production agent?
Permalink to “9. How do you evaluate a public skill before adopting it into a production agent?”Confirm the publisher, repository, revision, license, maintenance history, and complete file contents. Review scripts, commands, network calls, permissions, and dependencies, then test expected tasks, edge cases, and refusal paths in isolation. Verify that its business logic matches current policy and context. Assign an owner before production deployment.
10. Is there a hybrid approach between building a skill and adopting a public one?
Permalink to “10. Is there a hybrid approach between building a skill and adopting a public one?”Yes, but the result should be treated as a custom skill rather than a third category. A team can start with a licensed public structure or generic procedure, then replace organization-specific references, rules, tools, and tests. The resulting fork becomes an internally owned asset, even if the team continues to track upstream changes. This saves authoring time without outsourcing proprietary logic or production accountability.
Sources
Permalink to “Sources”- ToxicSkills: Malicious AI Agent Skills Supply Chain Compromise, Snyk. https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/
- Agent Skills security considerations, Anthropic. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
- Agent Skills specification. https://agentskills.io/specification
- Buy, boost, or build? Choose your path to generative AI, MIT Sloan. https://mitsloan.mit.edu/ideas-made-to-matter/buy-boost-or-build-choose-your-path-to-generative-ai
- Skill Drift Is Contract Violation, arXiv. https://arxiv.org/abs/2605.10990
- Agent Skills, Simon Willison. https://simonwillison.net/2025/Dec/19/agent-skills/
- What are skills?, Anthropic. https://support.claude.com/en/articles/12512176-what-are-skills
