Lessons from Building Claude Code: How We Use Skills构建 Claude Code 的经验：我们如何使用 Skills

Skills are one of the most widely used extension points in Claude Code precisely because they are lightweight to author and trivial to distribute — but that same flexibility makes it hard to know what's worth turning into a Skill.

Drawing on several hundred Skills in active internal use at Anthropic, the piece proposes a nine-category taxonomy and a set of authoring conventions that separate Skills people actually reuse from ones that quietly rot.

The piece opens from a practical tension: Skills lower the barrier to automating a workflow so much that almost anyone on the team can spin one up in minutes, but that same low barrier means there's no natural filter for quality. Left unmanaged, a team accumulates dozens of near-duplicate, half-documented Skills that nobody remembers the purpose of. The author frames the rest of the piece as an answer to 'given that Skills are easy to make, how do we make good ones on purpose?'

The nine-category taxonomy is the structural backbone of the argument. Rather than treating all Skills as instances of the same template, the piece separates them by the kind of work encoded — some inject domain-specific knowledge the model wouldn't otherwise have, others wrap an external tool or CLI into a natural-language interface, others codify a multi-step workflow that used to live in someone's head or a wiki page. Each category implies different tradeoffs: knowledge-injection Skills need to stay current and are prone to going stale, while workflow Skills need explicit ordering and failure-handling instructions.

A recurring theme is that trigger conditions are the single highest-leverage thing to get right. Because Skills are selected by the model based on their description, vague or overlapping triggers cause Claude to either miss an applicable Skill or invoke the wrong one. The fix proposed is treating the trigger description with the same rigor as a function signature — specific enough that a reader unfamiliar with the codebase could predict when it fires.

Scoping discipline is the second recurring theme: Skills that stay useful over time are narrowly bound to one recurring, well-defined task rather than a broad area of responsibility. A Skill that tries to cover 'anything related to deployments' degrades faster than one that covers 'roll back the staging environment to the last green build,' because the narrow one is easier to verify, easier to trust blindly, and easier for a new team member to adopt without reading every line.

The final arc shifts from individual authorship to team-level distribution, treating a Skill's promotion from personal to shared as analogous to publishing an internal library: it needs an owner, a discoverable location, and enough scrutiny that colleagues can trust it without re-verifying every run. This reframes Skills less as prompt engineering and more as a lightweight but real internal tooling practice.