In my first post about agent skills, I mentioned three skills that form my dev workflow: /new-issue, /next-task, and /approve. But /approve didn't start as its own skill.
My /next-task skill started as a single file that did everything: pick a task, implement it, open a PR, iterate on feedback, and merge when approved. It worked great. But after a few days I noticed a friction point. When I'd restart Claude mid-task — maybe I tweaked a setting or added an MCP server — the PR was already open but the merge logic was locked inside /next-task. I'd end up typing the merge steps manually instead of letting the agent handle it.
Sound familiar? It's the same instinct you get when a function inside a class wants to be extracted into its own module. The tell is simple: you want to use it in a context it wasn't designed for.
Here are the signs that indicate a sub-process is ready to become its own skill:
- You want to use it independently. The merge step is useful even when you didn't use
/next-taskto create the PR. - It has a clear start and end. Check if CI is green, verify no unresolved feedback, squash-merge. That's a self-contained process.
- Other skills could reference it. A shared skill means other skills can point to the same process.
The nice thing about skills is that you don't have to do the extraction by hand. You can describe what you want and let your agent do the refactoring. Here's a prompt to extract the skill from your /next-task skill:
Look at my /next-task skill. Extract everything after the user says "approved" into a new standalone /approve skill. The new skill should work on its own for any PR. Update /next-task to reference /approve for the merge step instead of duplicating the logic.Look at my /next-task skill. Extract everything after the user says "approved" into a new standalone /approve skill. The new skill should work on its own for any PR. Update /next-task to reference /approve for the merge step instead of duplicating the logic.From that prompt, Claude can read your existing /next-task skill, create a new /approve skill file, and update /next-task to point to it. The whole thing takes about thirty seconds. The resulting /approve skill handles the checks you want before merging. For me that's verifying checks are green, scanning for unresolved feedback, and only then squash-merging and cleaning up the branch. Small and focused — exactly what a good skill should be.
Another benefit is that the /next-task skill can get simpler, too. Its merge phase goes from a detailed procedure to a single line: "Follow the /approve skill to merge the PR." The agent knows how to find and follow that reference.
This pattern — start with one big skill, then extract sub-skills as they emerge — mirrors how good software evolves. You don't design the perfect architecture upfront. You let the structure reveal itself through use. The same applies here. I didn't plan for /approve to be its own skill when I originally wrote the /next-task skill. It earned its independence by proving it was useful in more than one context.
If you have a skill that's grown complex, look for the seams. Find the parts that make sense on their own and describe the extraction to your agent. You might be surprised how quickly your workflow becomes more composable.
Next, I'll round out this series on skills for dev workflow by building a /new-issue skill — the skill that feeds the whole pipeline.