The first Claude skill I built started with a task I knew too well: writing my weekly update.
The information lived across project tickets, Slack conversations, and documents. Every week, I gathered it, worked out what had changed, and translated it into something leadership could scan.
I could explain the process to another person. That gave me a starting point for explaining it to Claude.
A skill is a reusable set of instructions for a particular task. It captures the workflow, the context, and what a useful result should look like, so you don’t have to reconstruct those instructions every time.
I built mine through conversation in Claude Code. I didn’t write code, but I did have to get specific about how the work should happen.
Here’s the process I’d suggest to another PM.
1. Pick a task you understand
Start with something you already do often enough to recognize a good result.
A weekly update is a useful candidate. So is preparing for standup or drafting release notes. You know the inputs, the audience, and the mistakes that would make the output unusable.
Before opening Claude, write down:
- What task do I want help with?
- What steps do I follow?
- What information do I need, and where does it live?
- What should the output look like?
- Where do I need to review or make a decision?
A rough list is enough. If you’re struggling to describe the task, narrow it.
“Help with stakeholder communication” leaves too much open. “Draft a weekly project update from these sources, using this format, and flag anything that needs my confirmation” gives you something you can test.
2. Get a small version working
I use Claude Code through its chat panel in VS Code. If you’re starting there, follow Anthropic’s VS Code setup instructions to install the extension and sign in.
You don’t need every work tool connected before trying your first skill. Start with a few reference files you can provide directly. Connections to systems such as Slack or Jira are separate setup work; writing a skill doesn’t automatically give Claude access to them.
For a first attempt, you could ask:
Help me create a Claude Code skill called weekly-update. It should read the project notes I provide and draft a concise update for leadership. Organize it into progress, risks, and next steps. Flag missing information instead of filling it in. Show me the findings before drafting, and don’t send or publish anything.
Then add your process, an example of a good update, and any terminology the audience needs explained.
Ask Claude to identify what’s unclear before creating the skill.
The instructions live in a plain-text file called SKILL.md. Claude can help create the file and place it where Claude Code expects to find it. Anthropic’s skills documentation explains the file structure and how to run a skill.
Read the instructions it creates. Check whether they describe the process you intended.
3. Test against work you can check
Run the skill on a task where you know enough to assess the answer.
For my weekly update, the first version missed sources and gathered an incomplete picture. Some channels weren’t specified. Some relevant documents weren’t included. Instructions that seemed obvious to me turned out to be ambiguous.
Those problems became concrete changes to the skill.
If the output misses important context, specify where to look. If it’s too broad, narrow the time range or project scope. If the writing is wrong for the audience, provide an example and explain what makes it useful.
Also check how it handles gaps. I want it to tell me when a source is unavailable or a status is uncertain, rather than turn incomplete evidence into a confident update.
Try the revised instructions on another example. A skill that works once may still depend on context you happened to provide in that conversation.
4. Keep the decisions that need you
For my weekly update, gathering and drafting are separate steps.
The skill first presents its findings with supporting links. I review what it found, correct misunderstandings, and confirm what shipped. Then it drafts.
That pause gives me a chance to add context the source material doesn’t capture. Ticket activity alone won’t tell me whether a project is making meaningful progress or whether a risk needs leadership’s attention.
Write those review points into the instructions. Be explicit about whether the skill should produce a draft, save a file, or take an action after confirmation.
For a first version, a draft you can inspect is plenty.
5. Make it reusable when someone else needs it
My original skill knew my projects, channels, and terminology. That made it useful to me, but difficult for someone else to adopt.
When I made a version for other teams, I separated the workflow from the team-specific information.
The workflow described how to gather findings, review them, and draft the update. A separate configuration file held the projects, sources, owners, and audience details.
I added a setup conversation so the next person could answer questions instead of editing that file manually.
You don’t need this on day one. Get your own version working first. Once someone else wants to use it, you’ll have a clearer idea of what needs to stay consistent and what needs to change.
Keep improving it through use
Building and organizing my weekly-update skill took the better part of a day. That investment made sense for a task I repeated every week across several projects. A smaller, less frequent task might not justify the same effort.
I still edit the output. I also update the instructions when I find a recurring problem.
A useful prompt after a difficult run is:
Based on the corrections I made in this session, what should we change in the skill instructions?
Read the proposed changes before accepting them. Some corrections belong in the reusable workflow; others apply only to that week.
You don’t need to begin with an elaborate system. Pick one task you know, write down how you do it, and test whether the instructions produce something useful. The first missing source or misunderstood step will give you a specific place to improve.