Turning the Repeatable Work Into a Skill
How a Sittally App Store release skill, and a ClickUp skill that lets engineers and product managers start from the same task, turned the agent from a helper into part of the workflow.
A couple of days ago I wrote about how agentic workflows changed the management side of my job, which was really about attention, since a notetaker can hold the record and leave me in the conversation. This post is the move I have been making since then, noticing the work I keep re-explaining and writing it down so the agent can run it without a fresh briefing every time.
When the agent already knows the sequence, the places it has to stop, and the shape of what I need back, it is participating in the work, and the only way I have found to get there is to spend the time up front on that context so I stop paying for it again on every run.
The App Store loop I was tired of holding in my head
Sittally is on the App Store, and getting the first build through review was a long conversation of certificates, review notes, a rejection, subscriptions that had to be attached to the version, another binary, and another set of notes. Once that path was clear, every update after it turned out to be the same chore with a new set of changes.
I would ask for a version bump, then remember to check the number against what was actually live in App Store Connect, because the version sitting in pubspec.yaml is the repo and the store is a different record. From there I would ask for the IPA and where the file landed so I could drop it on Transporter, then for review notes and promotional text, remembering that promotional text has to fit in 170 characters while What’s New gets a much larger box that still has to read like something a customer would want, with the reviewer walkthrough kept in the notes. Somewhere in there I would also ask whether privacy or terms needed a change, which they usually did not, unless the build actually collected something new or changed how money and legal language worked. What wears me out is spending the morning remembering the sequence, when I would rather spend it on whether this release is a patch or a feature people will notice.
This morning I stopped re-prompting that loop and turned it into a skill I can call on any project, which reads the repo version, asks what is currently live or last submitted, looks at what changed since that store release, and proposes one next marketing version and build number before it touches anything. I confirm, or I send a different number, and only after that does it bump pubspec.yaml and run the release IPA build, so when the archive finishes I get the path to the file, paste-ready App Review notes, promotional text with a character count, and What’s New written for the store listing. If the repo does not already have a demo login, a legal URL, or a product ID, it asks, and it leaves the commit alone until I say otherwise.
The pause before the bump is what I care about, because the skill can hold the character limits, the rule that a build number only goes up, and the split between notes for a reviewer and copy for a shopper, while I still decide whether the proposed version is the right story for what shipped and I still upload the binary and submit it. The attention that used to go into reconstructing the checklist now goes into that confirmation.
The context is the whole point
What makes the skill worth the time is everything I was tired of typing, from what not to touch and what a person has to confirm, to what the output has to look like so I can paste it and which facts have to be read from the project. Writing that down takes longer than one more chat, and it pays off the next time, and the time after that, because the agent is working from a description of the job that already includes the stops.
When I first started working this way, every run began with a briefing, where I would lay out the job, watch a pass come back, correct whatever it missed, and only then feel like we had arrived. What changes a week is when that briefing already exists, including the places I want a person in the loop, so I can show up for the decisions instead of rebuilding the job from scratch.
One skill, both hats
The same pattern is what I wanted for the team at ClickUp, where the thing I kept repeating was the handoff between product and engineering.
A feature used to start in one conversation and get rebuilt in another, since a product manager would write the problem, the constraints, and what done looked like, and an engineer would turn that into a task they could build from, often after a briefing, because the useful detail lived in the room, and if the owner changed we briefed again. I wrote about putting that context on the task so the next person inherits the same picture, and the skill I built for the team sits in front of that, where an engineer or a product manager can invoke the same thing and it stands up a task that already carries the context both roles would have assembled on their own, then continues into the code and the pull request for the feature.
Either role can start it, because the skill already holds the product framing, which is why the work exists and what done means, alongside the engineering framing, which is how that work should land in a branch, while the messy parts, which repo, which conventions, which fields belong on the task, stay in the skill so the person driving the chat can stay on the feature.
People still own the gates
The autonomy I want is the agent carrying the work from a clear start through the repetitive middle, while a person still judges the result before it ships, since a pull request is a handoff and that judgment stays with the people who review it.
ClickUp is still where that lifecycle lives, and as a task moves, the tracker notifies the people who need to look at the code or the design, the same way it would if someone had moved the status by hand, which is what keeps a skill honest when it can open a pull request, because the project tool pulls a person in at the moment the work is ready to be judged.
New teammates get something from the same setup, because history and requirements used to arrive as a tour, or as a doc that was almost current, and when the decisions live where an agent can read them, someone who just joined can ask what we already decided, why a constraint exists, and what the last attempt looked like, then get an answer in the language of the work while still deciding what to do with it.
Find the chore, then write the stops
When people talk about a 100x workflow, what has actually compounded for me is a pile of small skills, where I look for the thing I am about to explain again, write the sequence and the stops into a skill, and let the agent manage what sits underneath, whether that is version numbers, character limits, task fields, or the path from a requirement to a branch. I get the speed because I am not reconstructing that every time, and I get the clarity because the skill is a record of how the work is supposed to go, which the agent can read, and so can the teammate who has been here for years and the person who joined last week.
The Sittally release skill is a small example of that, and it is already the difference between a morning spent remembering App Store Connect and a morning spent deciding what the release is, while the ClickUp skill points the same idea at a team so product and engineering can start from one place and carry a feature through to a pull request without rebuilding the context in between. I am going to keep looking for the next chore that earns that treatment, and I am going to keep the confirmation in a person’s hands.