Every week, I write a Slack update summarizing progress across my team’s active projects. The goal is to give leadership something they can scan in two minutes.
Writing something that short took a surprising amount of time.
Each project had its own Slack channel, documentation, and Jira tickets. Keeping track of what moved, what shipped, and what was at risk took the better part of a Monday afternoon. Translating it into something a reader outside the team could understand took longer.
Some weeks, I ran out of time before I made it through the source material. The update would go out Tuesday. Sometimes Wednesday.
The task was familiar. It was also slow, repetitive, and entirely mine to do.
So I built a Claude Code skill to help me do it.
Gathering first, drafting second
A skill is a reusable set of instructions for a particular task. Mine is called write-weekly-update.
When I run it, it checks where we are in our planning cycle, then gathers recent activity for each project from Jira, Slack, and Notion. It searches for announcements of shipped work, too.
Before writing the update, it pauses and shows me a structured summary: the status of each project, work that may have shipped, links to the supporting information, and possible risks worth surfacing.
That pause matters. I can correct what it misunderstood, confirm what shipped, and add context that never made it into a ticket or Slack thread.
Only then does it draft the updates and, with my explicit confirmation, send them to my Slack DMs. I have to say “send it.” “Looks good” doesn’t count.
The process takes about ten minutes to gather and review the findings. The draft still needs editing before I share it with its intended audience.
I’m spending more of that time checking what matters and less of it opening tabs to find out what happened.
Making it useful beyond my own setup
My first version knew my projects, channels, and terminology. That specificity was why it worked.
It also meant someone else couldn’t pick it up without changing the instructions.
I built a second version that separates the workflow from the team-specific information. The first time someone runs it, Claude asks a series of setup questions: Which teams and projects do you cover? Where are the tickets and documents? Which Slack channels matter? Who owns each project? What terminology needs explaining to your audience?
It writes the answers into a configuration file and asks the user to confirm them.
The next run starts from that saved information. When a new planning cycle begins, the user can ask to update the configuration. Claude reads back what it has, asks what changed, and updates those details.
That setup conversation was an important part of making the workflow reusable. I didn’t want the next person to have to understand my configuration file before they could write their weekly update.
What still takes work
The skill is good at gathering information. The draft still needs my review and edits.
A project can have plenty of ticket activity without making meaningful progress. A quiet Slack channel doesn’t necessarily mean something is stuck. And a technically accurate description can still leave a leadership reader wondering why the work matters.
Those are distinctions I need to make.
There’s also a question of whether the setup effort is worth it. Building the skill and organizing the context took the better part of a day.
For a weekly update covering several teams and many projects, that investment can pay off quickly. For a short update on three projects every other week, writing it manually might be faster.
I wouldn’t start by automating every recurring task. I’d start with one where I already know the process well and spend enough time repeating it to notice.
For months, I’d been describing this problem to colleagues: several projects, information scattered across systems, and too much of Monday spent gathering it all. Building the skill meant writing that description precisely enough for Claude to follow, including where it should stop and ask me.
I didn’t write code. I worked out the sources, the sequence, the audience, and the decisions I still needed to make myself.
Now, when I sit down to write the update, I have the findings in front of me. I can spend my attention deciding what leadership needs to know.