I make skills two ways. The first is by hand. You notice a process you repeat. You know where the prompt starts, which tools it uses and what the end result is, step by step. That is a skill candidate, and you write it down.
For the second way, I am not rushing to create skills. I do the work. I develop software with my agent, and I do marketing, financial analysis, tax and accounting with it too.
Some of what a session teaches is a rule, and some is a skill. A rule is something the agent must always obey, so it goes in the rules file it reads at every launch, and that file must stay short, or it becomes manager number one's binder. A skill is a procedure it needs only sometimes, so it waits as a label until the job calls for it.
You just finished a session where the agent did the job perfectly, after you corrected it twenty times along the way. Tomorrow you need the same job done again. What do you do before you close today's session?
Save the whole conversation, word for word, all twenty corrections included; I save every session that way, not only the short log at the end. Then open a fresh session, so the work does not happen in the stupid tail of a long one. Ask the agent to read that conversation, and others like it, and reverse-engineer a skill from them, so next time you just invoke it. The twenty corrections are exactly what the skill has to contain, because they are the twenty places the agent goes wrong without you. For this kind of work I choose a model that thinks longer before it answers, because finding the pattern across sessions is higher cognitive work. Most of the skills in my folder were made exactly that way, and they are not only for testing: decks, ads, book covers, résumés. Save only the output, and tomorrow you make the same twenty corrections again.