Creating Skills
Not every repeated task deserves to become a skill. But some absolutely do.
The usual sign is simple: you keep having to remind the agent of the same process. Same steps, same tools, same inputs, same expected output, same caveats. At that point, you're not dealing with a one-off request anymore. You're looking at a workflow that wants to be packaged.
Before a skill exists, the pattern usually feels like: "Every time we do this, I have to explain the same setup again." Tolerable once. Wasteful the tenth time.
After the workflow becomes a skill, it changes: "This process already has a name, a documented way of working, examples, and known boundaries. Use that." That's not just a convenience improvement — it's operational memory. The workflow stops living half in your head and half in the agent's temporary context. It becomes reusable, teachable, and less fragile.
A good skill has a tight boundary. One problem, solved well. Clear about what it's for. Clear about what good output looks like. Clear about what assumptions it depends on. And useful outside one specific afternoon that never repeats.
Bad skill candidates are usually mushy — trying to absorb too many unrelated tasks, depending on hidden context nobody wrote down, only making sense if one specific person is explaining them live. That's not a skill. That's a habit with branding.
The right moment to speak up is when you notice a stable pattern forming. Every project kickoff needs the same prep. A research workflow always uses the same structure. A reporting format keeps proving useful. An SOP is mature enough to stop being passed around informally.
That's when to tell your agent: this should become a skill.
You're not commissioning a novelty project. You're asking for the workflow to harden into a tool. Your agent writes the SKILL.md documentation, structures the examples, defines the boundaries, and makes it repeatable. You don't need to build it yourself — you need to recognize when something's worth building.
The before-and-after matters. Before: repeated through memory, reminders, and manual explanation. After: captured with clear docs and examples so the agent can execute consistently and anyone else can pick it up without folklore.
Some skills will stay internal because they're specific to how the team works. Others may eventually be mature enough to share more broadly. Publishing is the last step, not the first. First, the skill needs to prove it solves a real repeated problem cleanly.
If you're repeating yourself, if the workflow is stable, and if the result would benefit from being reusable instead of improvised — it probably wants to become a skill. That's the moment when a good SOP stops being advice and starts becoming infrastructure.