我们在 Anthropic 内部构建并规模化数百个技能的过程中学到了什么。
技能已成为 Claude Code 中使用最广泛的扩展点之一。它们灵活、易于创建，也易于分发。
但这种灵活性也让人难以判断什么做法最有效。什么类型的技能值得做？如何组织一个技能的结构？什么时候该把它们分享给他人？
我们在 Anthropic 一直在 Claude Code 中广泛使用技能，目前有数百个技能处于活跃使用状态。以下是我们关于利用技能加速开发所学到的经验。
什么是技能？
技能是包含指令、脚本和资源的文件夹，智能体可以发现并使用它们，从而更准确、更高效地完成任务。本篇博客文章假定读者已熟悉技能基础知识；如果你是新手，请先从我们在 Skilljar 上的 智能体技能入门课程开始。
我们听到的关于技能的一个常见误解是，它们“只是 markdown 文件”。实际上，它们是文件夹，可以包含脚本、资产、数据等内容，供智能体发现、探索和操作。
在 Claude Code 中，技能还拥有丰富多样的配置选项，包括注册动态钩子。
我们发现，Claude Code 中一些最有效的技能会充分利用这些配置选项和文件夹结构。
技能的类型
在梳理了 Anthropic 内部所有技能之后，我们注意到它们可以归为九类。最好的技能能干净利落地归入其中一类；而那些试图做太多事情的技能会横跨好几类，反而让智能体感到困惑。这并不是一份权威清单，但它是一个有用的框架，可以帮助你发现自己技能库中的空白。
Claude Code 团队对我们内部的技能进行了分类，发现它们可以归入九个不同的类别。
1. 库与 API 参考
这类技能说明如何正确使用某个库、CLI 或 SDK。它们既可以是针对内部库的，也可以是针对 Claude Code 有时难以处理的常见库。这类技能通常包含一个参考代码片段文件夹，以及一份 Claude 在编写脚本时应避免的坑点清单。
示例包括：
billing-lib—— 你的内部计费库：边界情况、易踩的坑等。internal-platform-cli—— 你的内部 CLI 封装工具的每一个子命令，并附上何时使用它们的示例。sandbox-proxy——为开发工作配置你所在组织的出口网关：哪些主机可达、如何调试“连接被拒绝”错误、如何添加一条允许列表条目。
2. 产品验证
这些技能描述的是如何测试或验证你的代码是否正常工作。它们通常与 playwright、tmux 或其他外部工具配合使用以进行验证。
在内部，验证类技能对 Claude 输出质量的影响是最可衡量的。让一名工程师花一周时间专门把你的验证技能打磨到极致，可能是值得的。
可以考虑一些技巧，比如让 Claude 录制其输出的视频，这样你就能确切看到它测试了什么，或者对每一步的状态强制执行程序化断言。这些通常通过在技能中纳入各种脚本来实现。
示例包括：
signup-flow-driver——在无头浏览器中跑完注册 → 邮箱验证 → 引导流程，并在每一步设置用于断言状态的钩子checkout-verifier——用 Stripe 测试卡驱动结账 UI，验证发票确实落到了正确的状态tmux-cli-driver——用于交互式 CLI 测试，即你要验证的东西需要一个 TTY
3. 数据获取与分析
这些技能用于连接你的数据与监控技术栈。这类技能可能包含用于凭据获取数据的库、特定的仪表盘 id 等，以及关于常见工作流或获取数据方式的说明。
示例包括：
funnel-query——“我需要关联哪些事件才能看到注册 → 激活 → 付费”以及那张真正含有规范 user_id 的表cohort-compare——比较两个群组的留存率或转化率，标记具有统计显著性的差异，并链接到分群定义grafana——数据源 UID、集群名称、问题 → 仪表盘查找表datadog——字段参考（@request_id 与 trace_id）、服务列表、指标前缀约定
4. 业务流程与团队自动化
这些技能将重复性的工作流自动化成一条命令。这类技能通常是相当简单的指令，但可能对其他技能或 MCP 有更复杂的依赖。对于这些技能，将先前的结果保存到日志文件中，有助于模型保持一致，并反思工作流此前的执行情况。
示例包括：
standup-post——汇总你的工单跟踪系统、GitHub 活动以及此前的 Slack 消息 → 生成格式化的站会汇报，仅包含增量变化create-<ticket-system>-ticket——强制校验 schema（有效的枚举值、必填字段）以及创建后的工作流（通知评审人、在 Slack 中发送链接）weekly-recap——已合并的 PR + 已关闭的工单 + 部署 → 生成格式化的回顾帖
5. 代码脚手架与模板
这些技能用于为代码库中特定功能生成框架样板代码。你可以将这些技能与可组合的脚本结合使用。当你的脚手架涉及无法完全由代码覆盖的自然语言需求时，它们尤其有用。
示例包括：
new-<framework>-workflow——按照你的注解脚手架生成新的服务/工作流/处理器new-migration——你的迁移文件模板加上常见坑点create-app——预配置好你的认证、日志和部署配置的新内部应用
6. 代码质量与审查
这些技能用于在你的组织内部强制执行代码质量，并帮助审查代码。它们可以包含确定性脚本或工具，以实现最大程度的稳健性。你可能希望将这些技能作为 hooks 的一部分自动运行，或在 GitHub Action 中运行。
adversarial-review——启动一个全新视角的子智能体来进行批判、实施修复、反复迭代，直到发现的问题降级为吹毛求疵code-style——强制执行代码风格，尤其是 Claude 默认情况下做得不够好的风格。testing-practices——关于如何编写测试以及测试什么的指令。
7. CI/CD 与部署
这些技能帮助你在代码库中拉取、推送和部署代码。这些技能可能会引用其他技能来收集数据。
示例包括：
babysit-pr——监控 PR → 重试不稳定的 CI → 解决合并冲突 → 启用自动合并deploy-<service>——构建 → 冒烟测试 → 带错误率对比的渐进式流量发布 → 出现回归时自动回滚cherry-pick-prod——隔离 worktree → cherry-pick → 冲突解决 → 带模板的 PR
8. 运维手册
这些技能接收一个症状（例如 Slack 讨论串、告警或错误签名），执行跨多个工具的排查流程，并生成一份结构化报告。
示例包括：
<service>-debugging——为你的高流量服务映射症状 → 工具 → 查询模式oncall-runner——获取告警 → 检查常见嫌疑对象 → 格式化发现结果log-correlator——给定一个请求 ID，从所有可能接触过它的系统中拉取匹配的日志
9. 基础设施运维
这些技能执行日常维护和运维流程，其中一些涉及破坏性操作，因而受益于防护栏机制。这些技能让工程师在关键操作中更容易遵循最佳实践。
示例包括：
<resource>-orphans——查找孤立的 pod/volume → 发布到 Slack → 观察期 → 用户确认 → 级联清理dependency-management——你所在组织的依赖审批工作流cost-investigation——“我们的存储/出口流量账单为什么激增”，并附带具体的 bucket 和查询模式
制作技能的技巧
一旦你决定了要制作哪个技能，该如何编写它？以下是 Claude Code 团队在制作技能方面的一些最佳实践、技巧和诀窍
不要陈述显而易见的内容
Claude 已经知道如何编码，也能读取你的代码库。一个只是重述 Claude 默认就会做的事情的技能，只会增加上下文而不增加价值。如果你要发布一个主要关于知识的技能，请专注于那些能推动 Claude 跳出其常规思维方式的信息。
前端设计技能就是一个很好的例子；它由 Anthropic 的一位工程师通过与客户反复迭代、改进 Claude 的设计品味而构建，避免了像 Inter 字体和紫色渐变这类经典套路。
建立一个易错点章节
任何技能中信号最强的内容就是易错点章节。这些章节应当从 Claude 在使用你的技能时遇到的常见失败点中积累而来。理想情况下，你会随着时间推移更新你的技能，以捕捉这些易错点。
例如：
"subscriptions 表是仅追加的。你要的那一行是版本号最高的那一行，而不是最近的那一行 created_at。" "这个字段在 API 网关中叫 @request_id，在计费服务中叫 trace_id。它们是同一个值。" "即使 Stripe webhook 实际上没有处理成功，Staging 也会返回 200。请检查 payment_events 以获取真实状态。"
利用文件系统和渐进式披露
SKILL.md 文件指向了若干其他文件，Claude 可以在特定情况下引用它们。例如，如果某个任务处于挂起状态，它应该引用 stuck-jobs.md。
正如我们之前所说，一个技能是一个文件夹，而不仅仅是一个 markdown 文件。你应该把整个文件系统视为一种上下文工程和渐进式披露的形式。告诉 Claude 你的技能中有哪些文件，它会在适当的时候读取它们。
渐进式披露的最简单形式是指向其他 markdown 文件供 Claude 使用。例如，你可以将详细的函数签名和使用示例拆分到 references/api.md 中。
另一个例子：如果你的最终输出是一个 markdown 文件，你可以在 assets/ 中放入一个模板文件，供其复制和使用。
你可以拥有包含参考资料、脚本、示例等的文件夹，这些能帮助 Claude 更高效地工作。
避免对 Claude 过度约束
Claude 通常会尽量遵循你的指令，而由于技能的可复用性很强，你需要小心不要在指令中写得过于具体。给 Claude 提供它所需的信息，但要给它灵活应变的空间。
例如：
想清楚配置流程
上面这个技能被编写为：如果配置中没有包含 Slack 频道，就提示用户。
有些技能可能需要结合用户的上下文来进行配置。例如，如果你要做一个把站会内容发布到 Slack 的技能，你可能希望 Claude 询问要发布到哪个 Slack 频道。
实现这一点的一个好模式是，像上面的示例那样，把这些配置信息存储在技能目录下的 config.json 文件中。如果配置尚未设置，智能体就可以向用户询问信息。
如果你希望智能体呈现结构化的多选题，可以指示 Claude 使用 AskUserQuestion 工具。
为模型撰写描述，而不是为人类撰写
当 Claude Code 启动一个会话时，它会构建一份包含所有可用技能及其描述的列表。Claude 正是扫描这份列表来判断"有没有针对这个请求的技能？"这意味着 description 字段不是摘要，而是对何时触发该技能的描述。
在技能的描述中加入触发词会很有帮助，比如“babysit”。
帮助 Claude 记忆
这个文本日志文件帮助 Claude 记住过去的事件，比如审查 Sarah 的 auth PR。
有些技能可以通过在其中存储数据来实现某种形式的记忆。你可以把数据存储在任意简单的东西里，比如仅追加的文本日志文件或 JSON 文件，也可以存储在复杂如 SQLite 数据库的东西里。
例如，一个 standup-post 技能可能会保留一个 standups.log，记录它写过的每篇帖子，这意味着下次你运行它时，Claude 会读取自己的历史记录，并能说出自昨天以来发生了什么变化。
你可以使用环境变量 ${CLAUDE_PLUGIN_DATA} 来获取一个稳定的目录，用于存储数据，在此处了解更多关于技能中持久化数据的内容：https://code.claude.com/docs/en/plugins-reference#persistent-data-directory。
存储脚本并生成代码
你能赋予 Claude 的最强大工具之一就是代码。给 Claude 提供脚本和库，能让它把回合花在组合编排上，决定下一步做什么，而不是重新构建样板代码。
例如，在你的 data-science 技能中，你可能有一个用于从事件源获取数据的函数库。为了让 Claude 进行复杂分析，你可以给它提供这样一组辅助函数：
Claude 随后可以即时生成脚本来组合这些功能，从而针对诸如“周二发生了什么？”这样的提示词执行更高级的分析。
使用按需钩子
技能可以包含仅在技能被调用时才激活、且仅在会话期间持续有效的钩子。对于那些你不想一直运行、但有时又极其有用的较为强硬的钩子，可以使用这种方式。
例如：
/careful``——通过 Bash 上的 PreToolUse 匹配器拦截 rm -rf、DROP TABLE、force-push、kubectl delete。你只希望在明确知道自己正在操作生产环境时才启用它——如果一直开着，会把你逼疯。/freeze—— 拦截任何不在指定目录内的 Edit/Write。在调试时很有用：“我想加日志，但总是手滑‘顺手修’了无关的代码。”
分发技能
技能最大的好处之一，就是你可以把它们分享给团队中的其他成员。
你可能希望通过两种方式与他人分享技能：
- 将你的技能检入仓库（位于
./.claude/skills下） - 制作一个 plugin，并搭建一个 Claude Code Plugin 市场，让用户可以上传和安装插件（更多内容请阅读文档）
对于在相对较少仓库上协作的小型团队来说，把技能检入仓库效果很好。但每一个被检入的技能也会给模型的上下文增加一点负担。随着规模扩大，内部插件市场可以让你分发技能，让团队自行决定安装哪些，同时还能包含一套安装流程。
管理技能市场
你如何决定哪些技能进入市场？人们又如何提交它们？
在 Anthropic，我们没有一支集中决策的团队；相反，我们尝试以有机的方式发现最有用的技能。如果有人有一个希望别人尝试的技能，他们可以把它上传到 GitHub 上的一个沙盒文件夹，并在 Slack 或其他论坛中引导大家前往查看。
一旦某个技能获得了关注（这由技能所有者自行判断），他们就可以提交一个 PR，将其移入市场。
组合技能
你可能会有一些相互依赖的技能。例如，你可能有一个负责上传文件的上传文件技能，以及一个生成 CSV 并上传它的 CSV 生成技能。这种依赖管理目前尚未原生内置于市场或技能中，但你只需按名称引用其他技能，模型就会在它们已安装的情况下调用它们。
衡量技能
为了了解某个技能的表现，我们使用了一个 PreToolUse 钩子，让我们能够在公司内部记录技能的使用情况（示例代码见此）。这意味着我们可以找出那些受欢迎的技能，或者那些相比我们的预期触发不足的技能。
技能的最佳实践仍在不断演进。我们大多数最好的技能最初都只是几行代码和一个单一的坑点，之后之所以变得更好，是因为随着 Claude 遇到新的边缘情况，人们不断往里面添加内容。
理解技能最好的方式就是动手开始、不断尝试，看看什么对你有效。
本文由 Thariq Shihipar 撰写，他是 Anthropic 的技术人员，从事 Claude Code 相关工作。
What we learned building and scaling hundreds of skills internally at Anthropic.
Skills have become one of the most used extension points in Claude Code. They’re flexible, easy to make, and easy to distribute.
But this flexibility also makes it hard to know what works best. What type of skills are worth making? How do you structure a skill? When do you share them with others?
We've been using skills in Claude Code extensively at Anthropic with hundreds of them in active use. These are the lessons we've learned about using skills to accelerate our development.
What are skills?
Skills are folders of instructions, scripts, and resources that agents can discover and use to do things more accurately and efficiently. This blog post assumes familiarity with skills basics; if you’re new, start with our Introduction to agent skills course on Skilljar.
A common misconception we hear about skills is that they are “just markdown files.” They’re actually folders that can include scripts, assets, data, etc. that the agent can discover, explore and manipulate.
In Claude Code, skills also have a wide variety of configuration options including registering dynamic hooks.
We’ve found that some of the most effective skills in Claude Code use these configuration options and folder structure effectively.
Types of skills
After cataloging all of our internal skills at Anthropic, we noticed they cluster into nine categories. The best skills fit cleanly into one; the ones that try to do too much straddle several and confuse the agent. This isn't a definitive list, but it is a useful framework for identifying gaps in your own skills library.
The Claude Code team categorized our internal skills and found that they could be bucketed into nine distinct categories.
1. Library and API reference
These are skills that explain how to correctly use a library, CLI, or SDKs. They could be both for internal libraries or common libraries that Claude Code sometimes struggles to handle. These skills often included a folder of reference code snippets and a list of gotchas for Claude to avoid when writing a script.
Examples include:
billing-lib— your internal billing library: edge cases, footguns, etc.internal-platform-cli— every subcommand of your internal CLI wrapper with examples on when to use them.sandbox-proxy— configuring your org's egress gateway for dev work: which hosts are reachable, how to debug "connection refused" errors, how to add an allowlist entry.
2. Product verification
These are skills that describe how to test or verify that your code is working. They are often paired with playwright, tmux, or other external tools for verification.
Verification skills have had the most measurable impact on Claude’s output quality internally. It can be worth having an engineer spend a week just making your verification skills excellent.
Consider techniques like having Claude record a video of its output so you can see exactly what it tested, or enforcing programmatic assertions on state at each step. These are often done by including a variety of scripts in the skill.
Examples include:
signup-flow-driver— runs through signup → email verify → onboarding in a headless browser, with hooks for asserting state at each stepcheckout-verifier— drives the checkout UI with Stripe test cards, verifies the invoice actually lands in the right statetmux-cli-driver— for interactive CLI testing where the thing you're verifying needs a TTY
3. Data fetching and analysis
These are skills that connect to your data and monitoring stacks. These skills might include libraries to fetch your data with credentials, specific dashboard ids, etc., as well as instructions on common workflows or ways to get data.
Examples include:
funnel-query— "which events do I join to see signup → activation → paid" plus the table that actually has the canonical user_idcohort-compare— compare two cohorts' retention or conversion, flag statistically significant deltas, link to the segment definitionsgrafana— datasource UIDs, cluster names, problem → dashboard lookup tabledatadog— field reference (@request_id vs trace_id), service list, metric prefix conventions
4. Business process and team automation
These are skills that automate repetitive workflows into one command. These skills are usually fairly simple instructions but might have more complicated dependencies on other skills or MCPs. For these skills, saving previous results in log files can help the model stay consistent and reflect on previous executions of the workflow.
Examples include:
standup-post— aggregates your ticket tracker, GitHub activity, and prior Slack → formatted standup, delta-onlycreate-<ticket-system>-ticket— enforces schema (valid enum values, required fields) plus post-creation workflow (ping reviewer, link in Slack)weekly-recap— merged PRs + closed tickets + deploys → formatted recap post
5. Code scaffolding and templates
These are skills that generate framework boilerplates for a specific function in a codebase. You might combine these skills with scripts that can be composed. They are especially useful when your scaffolding has natural language requirements that can’t be purely covered by code.
Examples include:
new-<framework>-workflow— scaffolds a new service/workflow/handler with your annotationsnew-migration— your migration file template plus common gotchascreate-app— new internal app with your auth, logging, and deploy config pre-wired
6. Code quality and review
These are skills that enforce code quality inside of your org and help review code. These can include deterministic scripts or tools for maximum robustness. You may want to run these skills automatically as part of hooks or inside of a GitHub Action.
adversarial-review— spawns a fresh-eyes subagent to critique, implements fixes, iterates until findings degrade to nitpickscode-style— enforces code style, especially styles that Claude does not do well by default.testing-practices— instructions on how to write tests and what to test.
7. CI/CD and deployment
These are skills that help you fetch, push, and deploy code inside of your codebase. These skills may reference other skills to collect data.
Examples include:
babysit-pr— monitors a PR → retries flaky CI → resolves merge conflicts → enables auto-mergedeploy-<service>— build → smoke test → gradual traffic rollout with error-rate comparison → auto-rollback on regressioncherry-pick-prod— isolated worktree → cherry-pick → conflict resolution → PR with template
8. Runbooks
These are skills that take a symptom (such as a Slack thread, alert, or error signature), walk through a multi-tool investigation, and produce a structured report.
Examples include:
<service>-debugging— maps symptoms → tools → query patterns for your highest-traffic servicesoncall-runner— fetches the alert → checks the usual suspects → formats a findinglog-correlator— given a request ID, pulls matching logs from every system that might have touched it
9. Infrastructure operations
These are skills that perform routine maintenance and operational procedures, some of which involve destructive actions that benefit from guardrails. These make it easier for engineers to follow best practices in critical operations.
Examples include:
<resource>-orphans— finds orphaned pods/volumes → posts to Slack → soak period → user confirms → cascading cleanupdependency-management— your org's dependency approval workflowcost-investigation— "why did our storage/egress bill spike" with the specific buckets and query patterns
Tips for making skills
Once you've decided on the skill to make, how do you write it? These are some of the Claude Code team’s best practices, tips, and tricks for making skills
Don’t state the obvious
Claude already knows how to code and can read your codebase. A skill that restates what Claude would do by default adds context without adding value. If you’re publishing a skill that is primarily about knowledge, focus on information that pushes Claude out of its normal way of thinking.
The frontend design skill is a great example; it was built by an engineer at Anthropic by iterating with customers on improving Claude’s design taste, avoiding classic patterns like the Inter font and purple gradients.
Build a gotchas section
The highest-signal content in any skill is the Gotchas section. These sections should be built up from common failure points that Claude runs into when using your skill. Ideally, you will update your skill over time to capture these gotchas.
For example:
"The subscriptions table is append-only. The row you want is the one with the highest version, not the most recent created_at." "This field is called @request_idin the API gateway and trace_id in the billing service. They're the same value." "Staging returns 200 even when the Stripe webhook didn't actually process. Check payment_eventsfor the real state."
Use the file system and progressive disclosure
The SKILL.md file points to several other files Claude can reference for specific situations. For example, if a job is pending, it should reference stuck-jobs.md.
Like we said earlier, a skill is a folder, not just a markdown file. You should think of the entire file system as a form of context engineering and progressive disclosure. Tell Claude what files are in your skill, and it will read them at appropriate times.
The simplest form of progressive disclosure is to point to other markdown files for Claude to use. For example, you may split detailed function signatures and usage examples into references/api.md.
Another example: if your end output is a markdown file, you might include a template file for it in assets/ to copy and use.
You can have folders of references, scripts, examples, etc., which help Claude work more effectively.
Avoid railroading Claude
Claude will generally try to stick to your instructions, and because skills are so reusable you’ll want to be careful of being too specific in your instructions. Give Claude the information it needs, but give it the flexibility to adapt to the situation.
For example:
Think through the setup
The skill above is written to prompt the user if the Slack channel is not included in the configuration.
Some skills may need to be set up with context from the user. For example, if you are making a skill that posts your standup to Slack, you may want Claude to ask which Slack channel to post it in.
A good pattern to do this is to store this setup information in a config.json file in the skill directory like the above example. If the config is not set up, the agent can then ask the user for information.
If you want the agent to present structured, multiple choice questions you can instruct Claude to use the AskUserQuestion tool.
Write descriptions for the model, not for humans
When Claude Code starts a session, it builds a listing of every available skill with its description. This listing is what Claude scans to decide "is there a skill for this request?" Which means the description field is not a summary, it's a description of when to trigger this skill.
It’s helpful to include triggers for the skill, like “babysit,” in its description.
Help Claude remember
This text log file helps Claude remember past events like reviewing Sarah’s auth PR.
Some skills can include a form of memory by storing data within them. You could store data in anything as simple as an append only text log file or JSON files, or as complicated as a SQLite database.
For example, a standup-post skill might keep a standups.log with every post it's written, which means the next time you run it, Claude reads its own history and can tell what's changed since yesterday.
You can use the env variable ${CLAUDE_PLUGIN_DATA}to get a stable directory where you can store data, read more persisting data in skills here: https://code.claude.com/docs/en/plugins-reference#persistent-data-directory.
Store scripts and generate code
One of the most powerful tools you can give Claude is code. Giving Claude scripts and libraries lets Claude spend its turns on composition, deciding what to do next rather than reconstructing boilerplate.
For example, in your data-science skill you might have a library of functions to fetch data from your event source. In order for Claude to do complex analysis, you could give it a set of helper functions like this:
Claude can then generate scripts on the fly to compose this functionality to do more advanced analysis for prompts like “What happened on Tuesday?”
Use on-demand hooks
Skills can include hooks that are only activated when the skill is called, and that only last for the duration of the session. Use this for more opinionated hooks that you don’t want to run all the time, but are extremely useful sometimes.
For example:
/careful``— blocks rm -rf, DROP TABLE, force-push, kubectl delete via PreToolUse matcher on Bash. You only want this when you know you're touching prod — having it always on would drive you insane./freeze— blocks any Edit/Write that's not in a specific directory. Useful during debugging: "I want to add logs but I keep accidentally 'fixing' unrelated code.”
Distributing skills
One of the biggest benefits of skills is that you can share them with the rest of your team.
There are two ways you might want to share skills with others:
- check your skills into your repo (under
./.claude/skills) - make a plugin and have a Claude Code Plugin marketplace where users can upload and install plugins (read more on the documentation here)
For smaller teams working across relatively few repos, checking your skills into repos works well. But every skill that is checked in also adds a little bit to the context of the model. As you scale, an internal plugin marketplace allows you to distribute skills and let your team decide which ones to install, as well as include a setup flow.
Managing a skills marketplace
How do you decide which skills go in a marketplace? How do people submit them?
At Anthropic, we don't have a centralized team that decides; instead we try to find the most useful skills organically. If someone has a skill that they want people to try out, they can upload it to a sandbox folder in GitHub and point people to it in Slack or other forums.
Once a skill has gotten traction (which is up to the skill owner to decide), they can put in a PR to move it into the marketplace.
Composing skills
You may want to have skills that depend on each other. For example, you may have a file upload skill that uploads a file, and a CSV generation skill that makes a CSV and uploads it. This sort of dependency management is not natively built into marketplaces or skills yet, but you can just reference other skills by name, and the model will invoke them if they are installed.
Measuring skills
To understand how a skill is doing, we use a PreToolUse hook that lets us log skill usage within the company (example code here). This means we can find skills that are popular or are undertriggering compared to our expectations.
Skills best practices are still evolving. Most of our best skills began as a few lines and a single gotcha, then got better because people kept adding to them as Claude hit new edge cases.
The best way to understand skills is to get started, experiment, and see what works for you.
This article was written by Thariq Shihipar, a member of technical staff at Anthropic, working on Claude Code.