Nobody sits down and says “today I will build a skill.” That’s not how it happens.
What happens is: someone finds a useful tool, wants to share it with their community, asks Claude to help, and somewhere in the middle of doing that thing, notices it has a shape. A repeatable shape. And then they capture the shape.
That’s the whole story. But the details are worth unpacking.
the setup
The tool was Expect, an AI browser testing thing that tries to break your website and records the session. Worth sharing with the Code for Creatives community. So the instruction to Claude was: “post this to DFOS.”
DFOS is the platform the C4C community runs on. It has an MCP server, which means Claude can talk to it directly from the terminal. Read channels, send messages, search posts, all through tool calls. No browser, no copy-paste. When Claude calls the DFOS MCP to send a message, it shows up under the user’s name with their permissions.
Claude drafted a post for the #try channel. The user read it, adjusted the format (“put it all in one message”), approved it. Claude sent it.
Then: “Add it to the wiki too.”
There’s a local wiki for tools and resources. Markdown files in a folder, indexed. Claude created a page for Expect, wrote up what it does, how to install it, a usage example, and linked it from the index.
Two tasks. Both done. Session over, probably.
Except: “Can you make this a skill?”
the question that matters
That question is the key moment in any session where a skill might emerge.
Notice what’s being asked about. Not the tool. The process. The sequence that just happened: find a tool, draft a DFOS post, get human approval, send it, update the wiki. That whole flow. Captured so next time something worth sharing comes up, you type /dfos-wiki and the process runs.
So Claude built it. A SKILL.md that knows the channel ID, the wiki location, the voice rules for how posts sound, and the approval gate. The human reviews the draft before anything goes out. That review step is not optional.
The whole session took maybe 20 minutes.
three things worth taking from this
Skills come from doing, not planning. The session didn’t start with “let’s design a skill.” It started with a task. The skill was extracted from the task after the fact, once the shape was visible. If you try to design skills from scratch, you’ll build abstract ones that never quite fit. Do the thing first.
“Agent or skill?” is the diagnostic question. At some point in any recurring workflow, ask it out loud. An agent is automated, it runs without you. A skill runs with you. This one needed a human in the middle, reviewing the draft before it goes to a real community channel. That makes it a skill. The approval gate is the whole point, not a limitation.
20 minutes is enough for a complete loop. Find something useful, share it, document it, capture the sharing process as a repeatable thing. That’s small, but it’s complete. The skills that actually get used are usually the ones built this way, from real tasks, not from theorizing about what would be handy.
the takeaway
Skills are noticed, not invented. The next one you build probably won’t start as “let me build a skill.” It’ll start as a task that goes well, and somewhere in the middle of doing it, you’ll see the shape.
That’s when you say “can you make this a skill?” and the answer will almost always be yes.