
The Right Way to Use Skills: Five Reflections Following Anthropic’s Public Release of Its Internal Methodology
TechFlow Selected TechFlow Selected

The Right Way to Use Skills: Five Reflections Following Anthropic’s Public Release of Its Internal Methodology
Many people use Skill, but they may not truly understand it.
Author: AI Product A Ying
I read a blog post by the Anthropic team titled “Lessons from Building Claude Code: How We Use Skills.” This is arguably the most in-depth practical summary of Skills I’ve encountered so far.
Skills themselves aren’t complicated—but doing them well is no easy task.
I recall when Skills first gained popularity, people loved building all kinds of “writing style” Skills or “content generation” Skills. It felt like as long as you injected your personal writing style into a Skill, the model would reliably output in that style.
But after testing many such Skills myself, I found they often simply didn’t work.
A single writing-style Skill might contain several thousand—or even tens of thousands—of characters. Loading it consumes a large chunk of context. And once context becomes overloaded, the model’s reasoning ability tends to degrade.
The result? You get the right tone—but shallow content and weakened analytical capability.
Another common issue:
Many people write Skills by stuffing them with step-by-step operational instructions: “Step 1 do X; Step 2 do Y; Step 3 do Z.” But in practice, model execution proves unstable.
Only later did I realize that repetitive, procedural tasks are better codified as Scripts—not spelled out as lengthy Instructions.
After reading Anthropic’s article, my biggest takeaway was this: Many people use Skills—but few truly understand them.
At its core, a Skill is Context Engineering. Knowing *when* to encode knowledge directly into a Skill, *when* to break it down into References, *when* to formalize it as a Script, and *when* to constrain the model using Gotchas—that’s where real expertise lies.
Once you grasp how Skills actually operate, revisiting exemplary ones reveals they’re never just about prompt engineering—they solve problems around context management, experience capture, and capability reuse.
If you want to dive deep into Skills, I highly recommend these two articles:
https://claude.com/blog/lessons-from-building-claude-code-how-we-use-skills
#01 Don’t Write Fluff
A Skill fundamentally captures an organization’s “tacit knowledge.” So avoid repeating common-sense facts the model already knows. What’s truly valuable is precisely what the model *doesn’t* know.
Anthropic internally stresses that Skills should focus on Gotchas—the pitfalls people routinely fall into.
For example:
1. Never sort this table by created_at.
2. A 200 response from staging does *not* indicate success.
3. request_id and trace_id refer to the same identifier.
Such details live only in employees’ lived experience. Always remember what a Skill really is:
Skill = Documenting the veteran engineer’s hard-won experience.
Through Skills, we consolidate fragmented expertise scattered across individual minds.
#02 A Skill Is Context Engineering
This may be one of Anthropic’s most profound insights.
A Skill isn’t just a Markdown file—it’s a folder. To those already using Skills, this sounds obvious.
Yet over the past few days, I’ve reflected deeply—and realized: They deliberately use the folder structure to embody the philosophy of Context Engineering.
Let’s revisit a typical Skill structure:
skill/
├── SKILL.md
├── references/ &
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














