The biggest mistake people make with skills is starting from the format. Start from the task. A skill is only as good as the method inside it, and the method already exists: it is whatever you do, in whatever order, when you do the task well. Writing the skill is mostly the act of noticing your own steps.
Step 1: pick one repeated task
The best first skill is a task you have done at least three times the same way, with a clear finished output. Renewal call prep. A support escalation summary. An account research brief. A weekly operating report. Avoid vague ambitions ("help me with sales") and one-off requests: a skill earns its keep through repetition. If you cannot name the output in one sentence, pick a different task.
Step 2: write the method in plain language
The heart of a skill is a markdown file that answers four questions, in order. When does this apply? What are the steps? What does it need? What does done look like? Write it the way you would brief a smart new colleague:
| Part | What to write | Example (renewal call prep) |
|---|---|---|
| When to use | The trigger, in one or two sentences. | "Use when preparing a renewal call for an existing account." |
| Steps | The method, in order, with decisions spelled out. | "Pull open tickets and recent notes. Check product usage trend. Flag pricing changes. Build a one page risk summary." |
| Inputs | The files and tools the method depends on. | "pricing-grid.pdf, the account's CRM record." |
| Output | The exact shape of the finished work. | "One page: risk level, three talking points, one suggested opener." |
One detail matters more than people expect: the skill's short description. Claude reads it to decide when the skill applies. "Prepare a renewal call brief from account context" gets picked up at the right moment; "sales helper" does not.
Step 3: add reference files and one worked example
Keep the instruction file short and move heavy material into reference files: the price list, the escalation policy, the report template. Claude reads them only when the skill needs them, which keeps the skill fast and current: update the price list file once and the method stays the same. Then add one real, finished example of the output. A single good example does more for consistency than three paragraphs of description.
Step 4: test it on real cases
Run the skill on two or three past cases where you know what a good output looked like, and compare. Where the result differs from what you would have done, the instructions are missing a decision you make without noticing. Write that decision down and run it again. Two or three passes are usually enough for the skill to hold.
Step 5: ship it to the team
A skill that lives in your local folder helps one person. The point of writing it is the moment it ships: a named owner, a version, an approval from the team lead (the domain expert, not IT), and a place in the company's skill library so the whole team runs the same current version. This is the loop we build knacks around: publish, approve, ship, use, improve. Write once, and every teammate starts from your best version.
How knacks helps
knacks turns this whole guide into a form. You describe the method in plain English, attach the files, and knacks drafts the skill with examples and tests. Your team lead approves it, it ships to everyone's Claude with nothing to install, and when you improve it, the whole team is on the new version the same day. No capture and no usage tracking, ever: nothing enters knacks unless you choose to publish it.
Write your first team skill this week.
Book a walkthrough. Bring one repeated task, and leave with your first skill: published, approved, and shipped to your team.
Book a walkthrough