$ man context-wiki/skills

A skill is a markdown file that captures HOW you do something. Write it once in plain English. Claude follows it every time. The /deploy skill knows how to stage, commit, push, and verify deploys across three websites. The /finalcopy skill knows your voice guide, platform rules, and anti-slop filters. The /tracker skill knows how to scan git commits, count content pieces, calculate output scores, and generate a dashboard image. Skills are portable knowledge. They turn tribal knowledge into executable automation.

PATTERN

Joe Rhew nailed this analogy. A skill is like a cast iron skillet. You are not doing anything special. You are just cooking. But every time you use the skillet, it gets more seasoned. A skill you have refined 20 times is dramatically better than the one you wrote on day one. And you never set aside time to improve it. You just use it, notice an edge case, fix the edge case, and the skill gets better. My /deploy skill started as 10 lines: stage, commit, push. Now it handles commit message generation, build verification across three sites, error recovery, and post-deploy confirmation. I never scheduled time to improve it. I just deployed 50 times and fixed what broke.

PRO TIP

Standard Operating Procedures were written for humans to follow step by step. They go stale. People skip steps. Nobody updates them. Skills replace SOPs entirely. Instead of writing a document that a human reads and follows (with errors), you write a skill that an agent executes (without errors). The skill is the SOP, the executor, and the quality check all in one file. I have 40+ skills in my repo. /deploy, /tracker, /finalcopy, /substackpost, /partneronboard, /webreveal, /heyreach-export, /linkedin-recon, /daily-tracker. Every workflow I repeat more than twice becomes a skill. Every skill I use more than five times gets refined. The result is a library of automation that runs my entire GTM operation.

PATTERN

A SKILL.md file needs five things: 1. Trigger description. What activates this skill? Slash commands, keywords, phrases. 2. Context requirements. What files, data, or state does the agent need before executing? List them explicitly. 3. Step-by-step instructions. Written in plain English. Numbered steps. Clear enough that a new agent with no prior conversation context can follow them. 4. Output expectations. What does success look like? A deployed site? A generated file? A posted draft? 5. Edge case handling. What could go wrong? Port conflicts, build failures, missing data. How should the agent recover? If your skill file is missing any of these, the agent will improvise. And improvisation is where things break.

ANTI-PATTERN

A skill file that says "deploy the website" is not a skill. It is a wish. A real skill says: check for unstaged changes, stage all modified files, generate a commit message from the diff, commit with that message, push to origin main, wait for the Vercel build to complete, check all three deployment URLs, confirm 200 status codes, and report results. Vague skills produce inconsistent results. Specific skills produce reliable results. Write the skill as if you are onboarding a contractor who has never seen your codebase. Because that is exactly what every new agent session is.